ACM 인증서 관리 완벽 가이드

AWS Certificate Manager를 활용한 SSL/TLS 인증서 발급부터 갱신까지, 초보 개발자도 쉽게 따라할 수 있는 실무 중심 가이드입니다. HTTPS 적용이 처음이라도 괜찮습니다.

1. ACM이란 무엇인가?

신입 개발자 김개발 씨가 처음으로 웹사이트를 배포했습니다. 그런데 브라우저 주소창에 "주의 요함" 경고가 떴습니다.

팀장님이 다가와서 말했습니다. "HTTPS 인증서를 적용해야 해요.

ACM을 사용하면 쉽게 할 수 있어요."

**ACM(AWS Certificate Manager)**은 AWS에서 제공하는 SSL/TLS 인증서 관리 서비스입니다. 마치 공인인증서를 자동으로 발급받고 갱신해주는 시스템과 같습니다.

무료로 퍼블릭 인증서를 발급받을 수 있고, 자동 갱신까지 지원하여 인증서 만료 걱정을 덜 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# ACM 클라이언트 생성
acm_client = boto3.client('acm', region_name='us-east-1')

# 인증서 목록 조회
response = acm_client.list_certificates(
    CertificateStatuses=['ISSUED', 'PENDING_VALIDATION']
)

# 발급된 인증서 정보 출력
for cert in response['CertificateSummaryList']:
    print(f"도메인: {cert['DomainName']}")
    print(f"인증서 ARN: {cert['CertificateArn']}")
    print("---")

김개발 씨는 회사에서 처음으로 웹사이트 배포를 맡게 되었습니다. 개발 서버에서는 잘 동작하던 웹사이트를 실제 도메인에 올리고 접속해보니, 브라우저가 빨간 경고창을 띄웠습니다.

"안전하지 않은 연결입니다." 당황한 김개발 씨에게 팀장 박시니어 씨가 다가왔습니다. "아, HTTPS 인증서를 아직 적용하지 않았네요.

ACM을 사용하면 5분이면 해결할 수 있어요." 그렇다면 ACM이란 정확히 무엇일까요? 쉽게 비유하자면, ACM은 마치 자동차 보험을 관리해주는 시스템과 같습니다.

보험 가입 신청을 하면 자격을 확인하고, 보험증을 발급해주고, 만료일이 다가오면 자동으로 갱신해줍니다. ACM도 마찬가지로 웹사이트의 보안 인증서를 발급하고, 검증하고, 자동으로 갱신해주는 역할을 담당합니다.

HTTPS가 없던 시절에는 어땠을까요? 예전에는 웹사이트를 만들면 그냥 HTTP로 서비스했습니다.

하지만 사용자가 입력한 비밀번호나 개인정보가 평문으로 전송되어 누구나 가로챌 수 있었습니다. 해커들은 중간에서 데이터를 훔쳐보는 공격을 손쉽게 할 수 있었습니다.

이런 문제를 해결하기 위해 SSL/TLS 인증서가 등장했습니다. 하지만 인증서를 발급받으려면 비용을 지불해야 했고, 매년 갱신해야 했으며, 설정도 복잡했습니다.

많은 개발자들이 인증서 만료로 인한 장애를 경험했습니다. 바로 이런 문제를 해결하기 위해 AWS Certificate Manager가 등장했습니다.

ACM을 사용하면 무료로 인증서를 발급받을 수 있습니다. AWS 리소스(ALB, CloudFront 등)에서 사용하는 퍼블릭 인증서는 완전히 무료입니다.

또한 자동 갱신 기능으로 인증서 만료 걱정이 없습니다. 무엇보다 간편한 통합이라는 큰 이점이 있습니다.

클릭 몇 번으로 로드밸런서나 CloudFront에 인증서를 적용할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 boto3 라이브러리로 ACM 클라이언트를 생성합니다. region_name을 'us-east-1'로 지정한 점이 중요합니다.

CloudFront에서 사용할 인증서는 반드시 버지니아 북부 리전에서 발급받아야 하기 때문입니다. 다음으로 list_certificates 함수로 발급된 인증서 목록을 조회합니다.

상태 필터를 사용하여 발급 완료된 인증서와 검증 대기 중인 인증서만 가져옵니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 웹사이트를 운영한다고 가정해봅시다. 고객들이 결제 정보를 입력하는 페이지에서는 반드시 HTTPS를 사용해야 합니다.

ACM으로 인증서를 발급받고 Application Load Balancer에 적용하면, 모든 트래픽이 암호화되어 안전하게 전송됩니다. 카카오페이, 네이버페이 같은 대형 서비스들도 이런 방식으로 고객 데이터를 보호하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 리전을 잘못 선택하는 것입니다.

ALB용 인증서는 해당 리전에서 발급받아야 하지만, CloudFront용 인증서는 반드시 us-east-1에서 발급받아야 합니다. 리전을 잘못 선택하면 인증서를 다시 발급받아야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 AWS 콘솔에서 ACM 서비스를 선택하면 되는 거군요!" ACM을 제대로 이해하면 보안이 강화된 웹사이트를 쉽게 운영할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - CloudFront에서 사용할 인증서는 반드시 us-east-1 리전에서 발급받으세요

와일드카드 인증서(*.example.com)를 사용하면 모든 서브도메인에서 사용할 수 있습니다
ACM은 AWS 리소스에서만 사용 가능하며, EC2 인스턴스에 직접 설치는 불가능합니다

2. 퍼블릭 인증서 요청

김개발 씨가 ACM 콘솔에 처음 접속했습니다. "인증서 요청" 버튼을 클릭했지만, 어떤 옵션을 선택해야 할지 막막했습니다.

퍼블릭 인증서와 프라이빗 인증서, 어떤 차이가 있을까요?

퍼블릭 인증서는 외부 사용자가 접근하는 웹사이트에서 사용하는 인증서입니다. 마치 공공기관에서 발급받는 공식 신분증과 같습니다.

인터넷에 공개된 도메인에 대해 무료로 발급받을 수 있으며, 브라우저가 자동으로 신뢰하는 인증서입니다.

다음 코드를 살펴봅시다.

import boto3

# ACM 클라이언트 생성
acm_client = boto3.client('acm', region_name='ap-northeast-2')

# 퍼블릭 인증서 요청
response = acm_client.request_certificate(
    DomainName='example.com',
    # 서브도메인도 함께 보호
    SubjectAlternativeNames=[
        'example.com',
        'www.example.com',
        '*.example.com'  # 와일드카드로 모든 서브도메인 포함
    ],
    ValidationMethod='DNS'  # DNS 검증 방식
)

print(f"인증서 ARN: {response['CertificateArn']}")

김개발 씨는 회사 홈페이지 www.mycompany.com에 HTTPS를 적용하려고 합니다. ACM 콘솔을 열어보니 "퍼블릭 인증서 요청"과 "프라이빗 인증서 요청" 두 가지 옵션이 보였습니다.

박시니어 씨가 옆에서 말했습니다. "외부 사용자가 접속하는 사이트라면 퍼블릭 인증서를 선택하세요.

완전히 무료예요." 그렇다면 퍼블릭 인증서란 정확히 무엇일까요? 쉽게 비유하자면, 퍼블릭 인증서는 마치 여권과 같습니다.

정부에서 발급한 공식 신분증이며, 전 세계 어디서나 인정받습니다. 공항 직원들은 여권을 보고 신원을 확인합니다.

마찬가지로 브라우저는 퍼블릭 인증서를 보고 웹사이트의 신원을 확인하고 자동으로 신뢰합니다. 인증서가 없던 시절에는 어떤 문제가 있었을까요?

HTTP로만 통신하던 시절에는 모든 데이터가 평문으로 전송되었습니다. 카페에서 공용 와이파이를 사용할 때, 같은 네트워크에 있는 누군가가 여러분의 비밀번호를 가로챌 수 있었습니다.

실제로 2000년대 초반에는 이런 방식의 해킹 사고가 빈번했습니다. 더 큰 문제는 신뢰성이었습니다.

접속한 웹사이트가 진짜인지, 가짜 사이트는 아닌지 확인할 방법이 없었습니다. 피싱 사이트가 정상 사이트를 흉내 내도 사용자는 구분할 수 없었습니다.

바로 이런 문제를 해결하기 위해 SSL/TLS 퍼블릭 인증서가 등장했습니다. 퍼블릭 인증서를 사용하면 암호화 통신이 가능해집니다.

브라우저와 서버 사이의 모든 데이터가 암호화되어 중간에서 가로채도 내용을 알 수 없습니다. 또한 도메인 검증도 얻을 수 있습니다.

인증 기관이 도메인 소유권을 확인하므로, 가짜 사이트를 만들 수 없습니다. 무엇보다 브라우저 신뢰라는 큰 이점이 있습니다.

주소창에 자물쇠 아이콘이 표시되어 사용자에게 안전함을 알려줍니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 DomainName으로 메인 도메인을 지정합니다. 이것이 인증서의 주체가 됩니다.

다음으로 SubjectAlternativeNames에서 추가 도메인들을 나열합니다. www가 붙은 도메인과 와일드카드를 함께 지정하면 하나의 인증서로 모든 서브도메인을 보호할 수 있습니다.

ValidationMethod는 'DNS'로 설정하는 것이 일반적입니다. 이메일 검증보다 자동화하기 쉽고 관리가 편리하기 때문입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 운영한다고 가정해봅시다.

shop.example.com, api.example.com, admin.example.com 등 여러 서브도메인을 사용합니다. 이때 *.example.com 와일드카드 인증서 하나를 발급받으면 모든 서브도메인에서 사용할 수 있습니다.

쿠팡이나 마켓컬리 같은 대형 이커머스도 이런 방식으로 인증서를 관리합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 도메인 표기를 잘못하는 것입니다. example.com과 www.example.com은 서로 다른 도메인입니다.

둘 다 사용한다면 SubjectAlternativeNames에 모두 포함해야 합니다. 하나만 지정하면 다른 도메인에서는 인증서 오류가 발생합니다.

또 다른 실수는 와일드카드의 범위를 오해하는 것입니다. *.example.com은 한 단계 서브도메인만 커버합니다.

api.example.com은 보호되지만, v1.api.example.com은 보호되지 않습니다. 두 단계 서브도메인이 필요하면 별도로 추가해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 실행한 김개발 씨는 인증서 ARN을 받았습니다.

"이제 검증만 하면 되는 거죠?" 퍼블릭 인증서 요청을 제대로 이해하면 여러 도메인을 효율적으로 관리할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 와일드카드 인증서(*.example.com)를 사용하면 서브도메인 추가 시 인증서를 다시 발급받지 않아도 됩니다

DNS 검증이 이메일 검증보다 자동화하기 쉽고 관리가 편리합니다
인증서 요청 후 72시간 내에 검증을 완료하지 않으면 자동으로 만료됩니다

3. DNS 검증

인증서를 요청한 김개발 씨는 "검증 보류 중" 상태를 보고 당황했습니다. 박시니어 씨가 말했습니다.

"도메인이 정말 네 거라는 걸 증명해야 해요. Route 53에 CNAME 레코드를 추가하면 됩니다."

DNS 검증은 도메인 소유권을 증명하는 과정입니다. 마치 집 주소로 우편물을 받아서 본인 확인을 하는 것과 같습니다.

ACM이 제공하는 CNAME 레코드를 DNS에 추가하면, AWS가 자동으로 확인하고 인증서를 발급합니다.

다음 코드를 살펴봅시다.

import boto3

acm_client = boto3.client('acm', region_name='ap-northeast-2')
route53_client = boto3.client('route53')

# 인증서 상세 정보 조회
cert_arn = 'arn:aws:acm:ap-northeast-2:123456789012:certificate/abcd-1234'
cert_details = acm_client.describe_certificate(CertificateArn=cert_arn)

# DNS 검증 레코드 가져오기
for domain in cert_details['Certificate']['DomainValidationOptions']:
    record = domain['ResourceRecord']
    print(f"Name: {record['Name']}")
    print(f"Value: {record['Value']}")
    # 이 값들을 Route 53에 CNAME 레코드로 추가해야 합니다

김개발 씨가 인증서를 요청한 지 10분이 지났지만, 여전히 "검증 보류 중" 상태입니다. "뭔가 잘못된 건가?" 걱정이 되기 시작했습니다.

박시니어 씨가 화면을 보며 설명했습니다. "아직 도메인 소유권을 증명하지 않았잖아요.

누구나 다른 사람의 도메인으로 인증서를 요청할 수 있으니까, 진짜 주인인지 확인하는 절차가 필요해요." 그렇다면 DNS 검증이란 정확히 무엇일까요? 쉽게 비유하자면, DNS 검증은 마치 우편물로 본인 확인을 하는 것과 같습니다.

은행에서 카드를 발급할 때 등록된 주소로 우편물을 보냅니다. 그 우편물을 받을 수 있다면 그 주소의 실제 거주자라는 증거가 됩니다.

마찬가지로 ACM은 특정 DNS 레코드를 추가하라고 요청합니다. 그 레코드를 추가할 수 있다면 그 도메인의 실제 소유자라는 증거가 됩니다.

검증이 없다면 어떤 일이 벌어질까요? 만약 누구나 아무 도메인에 대해 인증서를 발급받을 수 있다면 큰 문제가 생깁니다.

해커가 naver.com 인증서를 발급받아 가짜 네이버 사이트를 만들 수 있습니다. 사용자들은 자물쇠 아이콘을 보고 안심하겠지만, 실제로는 피싱 사이트입니다.

이런 사태를 방지하기 위해 반드시 도메인 소유권을 검증해야 합니다. 바로 이런 보안 문제를 해결하기 위해 DNS 검증 방식이 등장했습니다.

DNS 검증을 사용하면 자동화가 가능해집니다. 한번 CNAME 레코드를 추가하면 인증서가 자동 갱신될 때도 같은 레코드를 사용합니다.

또한 빠른 처리도 얻을 수 있습니다. 이메일 검증은 메일을 확인해야 하지만, DNS 검증은 레코드 추가 후 몇 분이면 완료됩니다.

무엇보다 보안성이라는 큰 이점이 있습니다. DNS를 관리할 수 있다는 것은 도메인의 실제 소유자라는 강력한 증거입니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 describe_certificate로 인증서 상세 정보를 가져옵니다.

여기에는 검증에 필요한 DNS 레코드 정보가 포함되어 있습니다. 다음으로 DomainValidationOptions를 순회하면서 각 도메인별 검증 레코드를 확인합니다.

ResourceRecord에 CNAME의 이름과 값이 들어있습니다. 이 정보를 Route 53이나 다른 DNS 서비스에 추가하면 됩니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 스타트업에서 새로운 서비스를 런칭한다고 가정해봅시다.

newservice.mycompany.com 도메인으로 서비스를 오픈하려고 합니다. 인증서를 요청하고 ACM 콘솔에서 CNAME 레코드 정보를 확인합니다.

Route 53 콘솔로 이동하여 해당 레코드를 추가하면, 5분 안에 검증이 완료되고 인증서가 발급됩니다. 토스나 당근마켓 같은 회사들도 신규 서비스 런칭 시 이런 방식을 사용합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 CNAME 레코드를 잘못 추가하는 것입니다.

ACM이 제공한 이름과 값을 정확히 복사해야 합니다. 한 글자라도 틀리면 검증이 실패합니다.

특히 끝에 붙는 점(.)을 빼먹거나 추가하는 실수가 많습니다. 또 다른 실수는 DNS 전파 시간을 고려하지 않는 것입니다.

CNAME 레코드를 추가한 후 전 세계 DNS 서버에 전파되기까지 시간이 걸립니다. 보통 몇 분이면 되지만, 경우에 따라 최대 48시간까지 걸릴 수 있습니다.

조급하게 "왜 안 되지?"라고 생각하기보다는 여유를 가지고 기다려야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Route 53에 CNAME 레코드를 추가한 김개발 씨는 5분 후 "발급됨" 상태를 확인했습니다. "와, 이렇게 쉽게 되네요!" DNS 검증을 제대로 이해하면 인증서 발급을 자동화하고 안전하게 관리할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Route 53 사용 시 ACM 콘솔에서 "Route 53에서 레코드 생성" 버튼을 클릭하면 자동으로 추가됩니다

CNAME 레코드는 인증서가 자동 갱신될 때도 사용되므로 절대 삭제하지 마세요
외부 DNS 서비스 사용 시 TTL을 낮게 설정하면 검증 속도가 빨라집니다

4. 인증서 갱신

6개월 후, 김개발 씨는 갑자기 걱정이 되었습니다. "인증서 만료일이 다가오는데, 어떻게 갱신하지?" 박시니어 씨가 웃으며 말했습니다.

"ACM은 자동으로 갱신되니까 걱정 마세요."

ACM 인증서 자동 갱신은 만료 60일 전부터 시작되는 자동화된 프로세스입니다. 마치 자동이체로 보험료가 갱신되는 것처럼, DNS 검증 레코드가 유지되고 있으면 ACM이 알아서 갱신합니다.

수동 작업이 필요 없어 인증서 만료로 인한 장애를 예방할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

acm_client = boto3.client('acm', region_name='ap-northeast-2')

# 모든 인증서 조회
certificates = acm_client.list_certificates(CertificateStatuses=['ISSUED'])

# 만료일 확인
for cert_summary in certificates['CertificateSummaryList']:
    cert_arn = cert_summary['CertificateArn']
    cert_detail = acm_client.describe_certificate(CertificateArn=cert_arn)

    not_after = cert_detail['Certificate']['NotAfter']
    days_remaining = (not_after - datetime.now(not_after.tzinfo)).days

    print(f"도메인: {cert_detail['Certificate']['DomainName']}")
    print(f"만료일: {not_after.strftime('%Y-%m-%d')}")
    print(f"남은 기간: {days_remaining}일")
    print(f"갱신 상태: {cert_detail['Certificate'].get('RenewalEligibility', 'N/A')}")
    print("---")

6개월이 지난 어느 날, 김개발 씨는 갑자기 불안해졌습니다. 예전에 개인 프로젝트에서 Let's Encrypt 인증서를 사용했다가 갱신을 깜빡해서 웹사이트가 다운된 적이 있었습니다.

"우리 회사 사이트 인증서는 언제 만료되지?" 급하게 ACM 콘솔을 확인했습니다. 만료일이 3개월 후로 표시되어 있었지만, 상태는 여전히 "발급됨"이었습니다.

박시니어 씨가 커피를 마시며 말했습니다. "ACM은 자동으로 갱신되니까 신경 쓸 필요 없어요.

DNS 검증 레코드만 그대로 두면 됩니다." 그렇다면 ACM 자동 갱신은 정확히 어떻게 작동할까요? 쉽게 비유하자면, 자동 갱신은 마치 Netflix 구독과 같습니다.

매달 결제일이 되면 자동으로 결제되고 서비스가 계속 유지됩니다. 여러분이 할 일은 결제 수단(여기서는 DNS 레코드)이 유효한지만 확인하면 됩니다.

나머지는 시스템이 알아서 처리합니다. 수동 갱신이 필요했던 시절에는 어떤 문제가 있었을까요?

전통적인 SSL 인증서는 1년마다 수동으로 갱신해야 했습니다. 달력에 표시해두고, 만료 전에 인증 기관 웹사이트에 접속하여 갱신 절차를 진행해야 했습니다.

담당자가 퇴사하거나 휴가 중이면 갱신을 놓칠 수 있었습니다. 더 큰 문제는 갱신 실패로 인한 서비스 장애였습니다.

인증서가 만료되면 브라우저가 경고창을 띄우고, 많은 사용자들이 사이트 접속을 포기합니다. 실제로 2020년에 유명 금융 서비스가 인증서 만료로 수 시간 동안 서비스를 중단한 사례가 있었습니다.

바로 이런 문제를 해결하기 위해 ACM 자동 갱신 시스템이 설계되었습니다. ACM 자동 갱신을 사용하면 완전한 자동화가 가능해집니다.

만료 60일 전부터 ACM이 자동으로 갱신을 시도합니다. 또한 무중단 갱신도 얻을 수 있습니다.

새 인증서가 발급되면 연결된 AWS 리소스에 자동으로 적용되므로 서비스 중단이 없습니다. 무엇보다 관리 부담 제로라는 큰 이점이 있습니다.

한번 설정해두면 영구적으로 사용할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 list_certificates로 발급된 모든 인증서를 가져옵니다. 각 인증서의 ARN을 사용하여 상세 정보를 조회합니다.

NotAfter 필드에서 만료일을 확인할 수 있습니다. 현재 날짜와 비교하여 남은 기간을 계산합니다.

RenewalEligibility 필드를 보면 자동 갱신이 가능한 인증서인지 확인할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 대규모 이커머스 플랫폼을 운영한다고 가정해봅시다. 수십 개의 도메인과 서브도메인을 사용하고 있습니다.

각각의 인증서 만료일을 일일이 관리하는 것은 불가능합니다. ACM 자동 갱신을 사용하면 모든 인증서가 자동으로 갱신되어 관리 부담이 크게 줄어듭니다.

쿠팡이나 11번가 같은 대형 플랫폼도 이런 방식으로 인증서를 관리합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 DNS 검증 레코드를 삭제하는 것입니다. 도메인 정리 작업을 하다가 "이 CNAME은 뭐지?"하고 삭제해버리면, 자동 갱신이 실패합니다.

만료 60일 전부터 갱신을 시도하므로, 갱신 실패 알림을 받으면 즉시 DNS 레코드를 복구해야 합니다. 또 다른 실수는 사용 중이지 않은 인증서를 방치하는 것입니다.

ACM 인증서는 무료이지만, 계정당 발급 가능한 개수에 제한이 있습니다(기본 2,048개). 더 이상 사용하지 않는 인증서는 삭제하여 정리하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 실행한 김개발 씨는 모든 인증서가 "ELIGIBLE" 상태임을 확인했습니다.

"앞으로 갱신 걱정은 안 해도 되겠네요!" ACM 자동 갱신을 제대로 이해하면 인증서 관리에서 완전히 자유로워질 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 만료 45일, 30일, 15일 전에 갱신 실패 시 이메일 알림이 발송되므로 AWS 계정 이메일을 정기적으로 확인하세요

DNS 검증 레코드는 절대 삭제하지 마세요. 자동 갱신에 필수적입니다
CloudWatch Events로 갱신 실패 알림을 Slack이나 SNS로 전송하도록 설정할 수 있습니다

5. ALB와 CloudFront 연동

드디어 인증서를 발급받은 김개발 씨는 이제 실제로 웹사이트에 적용해야 합니다. "ALB 설정 화면에 인증서 선택 메뉴가 있네요?" 박시니어 씨가 고개를 끄덕입니다.

"맞아요. 클릭 몇 번이면 HTTPS가 활성화돼요."

ACM 인증서와 AWS 리소스 연동은 발급받은 인증서를 실제 서비스에 적용하는 과정입니다. 마치 자동차 보험증을 차량에 등록하는 것과 같습니다.

Application Load Balancer나 CloudFront 설정에서 인증서를 선택하기만 하면 HTTPS 통신이 활성화됩니다.

다음 코드를 살펴봅시다.

import boto3

# ELBv2 클라이언트 생성 (ALB 관리)
elbv2_client = boto3.client('elbv2', region_name='ap-northeast-2')

# HTTPS 리스너 생성
response = elbv2_client.create_listener(
    LoadBalancerArn='arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:loadbalancer/app/my-alb/1234567890abcdef',
    Protocol='HTTPS',
    Port=443,
    Certificates=[
        {
            # ACM 인증서 ARN 지정
            'CertificateArn': 'arn:aws:acm:ap-northeast-2:123456789012:certificate/abcd-1234'
        }
    ],
    DefaultActions=[
        {
            'Type': 'forward',
            'TargetGroupArn': 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/my-targets/1234567890abcdef'
        }
    ]
)

print(f"HTTPS 리스너 생성 완료: {response['Listeners'][0]['ListenerArn']}")

김개발 씨는 드디어 인증서를 손에 쥐었습니다. 아니, 정확히는 ACM 콘솔에서 "발급됨" 상태를 확인했습니다.

이제 실제 웹사이트에 적용할 차례입니다. "근데 이걸 어떻게 서버에 설치하지?" 전통적인 방식으로 생각한 김개발 씨는 인증서 파일을 다운로드하려고 했습니다.

박시니어 씨가 말했습니다. "ACM 인증서는 다운로드할 수 없어요.

대신 AWS 리소스에서 바로 선택해서 사용합니다. 훨씬 편해요." 그렇다면 ACM 인증서 연동은 정확히 어떻게 작동할까요?

쉽게 비유하자면, 인증서 연동은 마치 호텔 키카드 시스템과 같습니다. 프론트에서 방 번호를 등록하면 키카드가 자동으로 해당 방 문을 열 수 있게 됩니다.

키를 복사하거나 직접 들고 다닐 필요가 없습니다. 마찬가지로 ACM 인증서도 ARN만 지정하면 AWS 리소스가 자동으로 인증서를 사용합니다.

인증서를 수동으로 설치하던 시절에는 어떤 문제가 있었을까요? 전통적인 웹서버에서는 인증서 파일(.crt, .key)을 다운로드하여 서버에 업로드해야 했습니다.

Nginx나 Apache 설정 파일을 수정하고, 웹서버를 재시작해야 했습니다. 서버가 여러 대라면 모든 서버에 동일한 작업을 반복해야 했습니다.

더 큰 문제는 보안 위험이었습니다. 프라이빗 키 파일이 서버에 저장되므로, 서버가 해킹당하면 인증서도 탈취될 수 있었습니다.

또한 인증서 갱신 시 모든 서버에서 파일을 교체하고 재시작해야 하는 번거로움이 있었습니다. 바로 이런 문제를 해결하기 위해 AWS 리소스 통합 방식이 설계되었습니다.

ACM 통합 방식을 사용하면 원클릭 적용이 가능해집니다. 콘솔에서 인증서를 선택하기만 하면 즉시 HTTPS가 활성화됩니다.

또한 중앙 집중식 관리도 얻을 수 있습니다. 여러 ALB나 CloudFront 배포에서 같은 인증서를 공유하며, 갱신 시 모든 리소스에 자동 적용됩니다.

무엇보다 프라이빗 키 보안이라는 큰 이점이 있습니다. 키 파일이 서버에 노출되지 않아 탈취 위험이 없습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 create_listener로 ALB에 HTTPS 리스너를 추가합니다.

Protocol을 'HTTPS', Port를 443으로 설정하는 것이 표준입니다. Certificates 배열에 ACM 인증서의 ARN을 지정합니다.

여러 인증서를 추가하여 SNI(Server Name Indication)를 지원할 수도 있습니다. DefaultActions는 HTTPS 요청을 어느 대상 그룹으로 전달할지 정의합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 마이크로서비스 아키텍처로 구성된 서비스를 운영한다고 가정해봅시다.

api.example.com은 ALB를 통해 백엔드 서비스로 라우팅하고, www.example.com은 CloudFront를 통해 정적 콘텐츠를 제공합니다. 같은 와일드카드 인증서를 두 리소스에 모두 연결하면 일관된 보안을 유지할 수 있습니다.

배달의민족이나 야놀자 같은 서비스도 이런 아키텍처를 사용합니다. CloudFront 연동도 비슷한 방식으로 진행됩니다.

CloudFront 배포 설정에서 "Custom SSL Certificate" 옵션을 선택하고 ACM 인증서를 지정합니다. 단, CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받아야 한다는 점을 기억하세요.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 HTTP to HTTPS 리디렉션을 설정하지 않는 것입니다.

HTTPS 리스너만 추가하면 http://example.com으로 접속한 사용자는 연결 실패를 경험합니다. HTTP 리스너에 리디렉션 규칙을 추가하여 모든 트래픽을 HTTPS로 전환해야 합니다.

또 다른 실수는 보안 정책을 잘못 선택하는 것입니다. ALB의 보안 정책은 지원하는 TLS 버전과 암호화 스위트를 정의합니다.

너무 오래된 정책을 사용하면 보안에 취약하고, 너무 최신 정책을 사용하면 구형 브라우저가 접속할 수 없습니다. 일반적으로 ELBSecurityPolicy-TLS-1-2-2017-01 정책을 권장합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. ALB에 인증서를 연결한 김개발 씨는 https://www.mycompany.com으로 접속했습니다.

주소창에 자물쇠 아이콘이 떴습니다. "드디어 HTTPS가 적용됐어요!" ACM 인증서 연동을 제대로 이해하면 안전하고 확장 가능한 웹 인프라를 구축할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - ALB에서 HTTP(80) 리스너에 HTTPS(443)로 리디렉션 규칙을 추가하여 모든 트래픽을 보호하세요

CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받아야 합니다
SNI를 사용하면 하나의 ALB에서 여러 도메인에 대한 서로 다른 인증서를 사용할 수 있습니다

6. 프라이빗 인증서

며칠 후 김개발 씨는 새로운 요구사항을 받았습니다. "내부 직원들만 사용하는 관리자 시스템에도 HTTPS를 적용해야 해요." 박시니어 씨가 설명했습니다.

"외부에 공개되지 않은 도메인은 프라이빗 인증서를 사용해야 해요."

프라이빗 인증서는 조직 내부에서만 사용하는 인증서입니다. 마치 사내 ID 카드처럼 외부에서는 인정받지 못하지만 조직 내에서는 유효합니다.

AWS Private Certificate Authority를 통해 발급하며, VPN이나 내부 API 통신 암호화에 사용됩니다.

다음 코드를 살펴봅시다.

import boto3

# ACM PCA 클라이언트 생성
acm_pca_client = boto3.client('acm-pca', region_name='ap-northeast-2')
acm_client = boto3.client('acm', region_name='ap-northeast-2')

# 프라이빗 CA ARN (이미 생성되어 있다고 가정)
ca_arn = 'arn:aws:acm-pca:ap-northeast-2:123456789012:certificate-authority/abcd-1234'

# 프라이빗 인증서 요청
response = acm_client.request_certificate(
    DomainName='internal.mycompany.local',
    SubjectAlternativeNames=[
        'internal.mycompany.local',
        'admin.mycompany.local',
        '*.internal.mycompany.local'
    ],
    # 퍼블릭 인증서와 다르게 CA ARN 지정
    CertificateAuthorityArn=ca_arn,
    # 검증 불필요 (프라이빗 CA가 직접 발급)
)

print(f"프라이빗 인증서 ARN: {response['CertificateArn']}")

며칠 후 김개발 씨는 새로운 프로젝트를 시작했습니다. 사내 직원들만 VPN으로 접속하는 관리자 시스템입니다.

"이것도 HTTPS를 적용해야 하나요?" 박시니어 씨가 고개를 끄덕였습니다. "당연하죠.

내부 시스템이라고 해서 보안을 소홀히 하면 안 돼요. 하지만 퍼블릭 인증서는 사용할 수 없어요.

외부에 공개되지 않은 도메인이니까요." 그렇다면 프라이빗 인증서란 정확히 무엇일까요? 쉽게 비유하자면, 프라이빗 인증서는 마치 사내 ID 카드와 같습니다.

회사 건물 안에서는 출입증으로 사용할 수 있지만, 외부 은행이나 공공기관에서는 신분증으로 인정받지 못합니다. 마찬가지로 프라이빗 인증서는 조직 내부에서는 유효하지만, 일반 브라우저는 신뢰하지 않습니다.

내부 시스템에 보안이 없던 시절에는 어떤 문제가 있었을까요? 많은 기업들이 "어차피 내부망이니까 HTTP로 충분하다"고 생각했습니다.

하지만 내부자 위협이나 악성코드 감염 시 민감한 데이터가 그대로 노출되었습니다. 특히 원격 근무가 늘어나면서 VPN을 통한 내부 시스템 접속이 증가했고, 암호화되지 않은 통신은 큰 보안 구멍이 되었습니다.

더 큰 문제는 규정 준수였습니다. ISMS-P, ISO 27001 같은 정보보호 인증을 받으려면 내부 시스템도 암호화 통신을 사용해야 합니다.

감사 시 HTTP 통신이 발견되면 지적 사항으로 기록됩니다. 바로 이런 문제를 해결하기 위해 프라이빗 인증서 시스템이 등장했습니다.

프라이빗 인증서를 사용하면 내부 통신 암호화가 가능해집니다. 직원 노트북과 내부 서버 사이의 모든 데이터가 암호화됩니다.

또한 유연한 도메인 관리도 얻을 수 있습니다. .local, .internal 같은 공개되지 않은 도메인도 사용할 수 있습니다.

무엇보다 완전한 제어권이라는 큰 이점이 있습니다. 조직이 직접 인증 기관을 운영하므로 발급, 갱신, 폐기를 자유롭게 관리할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 acm-pca 클라이언트로 Private Certificate Authority를 관리합니다.

ca_arn은 미리 생성해둔 프라이빗 CA의 ARN입니다. request_certificate에서 CertificateAuthorityArn을 지정하는 것이 핵심입니다.

이 필드가 있으면 프라이빗 인증서로 발급됩니다. 퍼블릭 인증서와 달리 ValidationMethod가 필요 없습니다.

프라이빗 CA가 직접 발급하므로 도메인 검증 과정이 생략됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 금융 회사에서 내부 직원들이 사용하는 리스크 관리 시스템을 운영한다고 가정해봅시다. risk.internal.mybank.local 도메인으로 서비스하며, VPN 접속자만 사용할 수 있습니다.

프라이빗 인증서를 발급받아 내부 ALB에 적용하면, 직원들의 브라우저와 서버 사이 통신이 암호화됩니다. 또한 마이크로서비스 간 API 통신에도 mTLS(상호 TLS 인증)를 적용하여 보안을 강화할 수 있습니다.

Private CA 운영 비용을 알아야 합니다. 프라이빗 CA는 무료가 아닙니다.

CA 하나당 월 400달러의 비용이 발생합니다. 따라서 소규모 조직에서는 비용 대비 효과를 신중히 검토해야 합니다.

인증서 발급 자체는 개당 0.75달러이므로 많은 인증서를 발급할수록 효율적입니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 클라이언트 신뢰 설정을 빠뜨리는 것입니다. 프라이빗 인증서는 브라우저가 자동으로 신뢰하지 않습니다.

조직의 모든 클라이언트(직원 PC, 서버 등)에 프라이빗 CA의 루트 인증서를 설치해야 합니다. 이 작업을 하지 않으면 브라우저가 "신뢰할 수 없는 인증서" 경고를 표시합니다.

또 다른 실수는 프라이빗 CA 관리를 소홀히 하는 것입니다. CA의 프라이빗 키가 유출되면 전체 시스템의 보안이 무너집니다.

CA는 반드시 안전하게 보관하고, 접근 권한을 엄격히 제한해야 합니다. AWS Private CA는 HSM(Hardware Security Module)을 사용하여 키를 보호하므로 안전합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 프라이빗 인증서를 발급받고 내부 ALB에 적용한 김개발 씨는 VPN으로 접속하여 테스트했습니다.

처음에는 경고가 떴지만, IT팀이 전사 PC에 루트 인증서를 배포한 후에는 자물쇠 아이콘이 정상적으로 표시되었습니다. "내부 시스템도 이제 안전하네요!" 프라이빗 인증서를 제대로 이해하면 조직의 전체 네트워크를 end-to-end로 암호화할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Private CA는 월 400달러의 비용이 발생하므로, 소규모 조직은 Let's Encrypt 같은 대안을 고려하세요

프라이빗 CA의 루트 인증서를 모든 클라이언트에 배포해야 브라우저 경고가 사라집니다
마이크로서비스 간 mTLS 인증에 프라이빗 인증서를 활용하면 제로 트러스트 아키텍처를 구현할 수 있습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#ACM#SSL#Certificate#HTTPS

ACM 인증서 관리 완벽 가이드

# ACM 인증서 관리 완벽 가이드 AWS Certificate Manager를 활용한 SSL/TLS 인증서 발급부터 갱신까지, 초보 개발자도 쉽게 따라할 수 있는 실무 중심 가이드입니다. HTTPS 적용이 처음이라도 괜찮습니다. --- ## 목차 1. [ACM이란 무엇인가?](#acm이란-무엇인가?) 2. [퍼블릭 인증서 요청](#퍼블릭-인증서-요청) 3. [DNS 검증](#dns-검증) 4. [인증서 갱신](#인증서-갱신) 5. [ALB와 CloudFront 연동](#alb와-cloudfront-연동) 6. [프라이빗 인증서](#프라이빗-인증서) --- ## 1. ACM이란 무엇인가? 신입 개발자 김개발 씨가 처음으로 웹사이트를 배포했습니다. 그런데 브라우저 주소창에 "주의 요함" 경고가 떴습니다. 팀장님이 다가와서 말했습니다. "HTTPS 인증서를 적용해야 해요. ACM을 사용하면 쉽게 할 수 있어요." **ACM(AWS Certificate Manager)**은 AWS에서 제공하는 SSL/TLS 인증서 관리 서비스입니다. 마치 공인인증서를 자동으로 발급받고 갱신해주는 시스템과 같습니다. 무료로 퍼블릭 인증서를 발급받을 수 있고, 자동 갱신까지 지원하여 인증서 만료 걱정을 덜 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # ACM 클라이언트 생성 acm_client = boto3.client('acm', region_name='us-east-1') # 인증서 목록 조회 response = acm_client.list_certificates( CertificateStatuses=['ISSUED', 'PENDING_VALIDATION'] ) # 발급된 인증서 정보 출력 for cert in response['CertificateSummaryList']: print(f"도메인: {cert['DomainName']}") print(f"인증서 ARN: {cert['CertificateArn']}") print("---") ``` 김개발 씨는 회사에서 처음으로 웹사이트 배포를 맡게 되었습니다. 개발 서버에서는 잘 동작하던 웹사이트를 실제 도메인에 올리고 접속해보니, 브라우저가 빨간 경고창을 띄웠습니다. "안전하지 않은 연결입니다." 당황한 김개발 씨에게 팀장 박시니어 씨가 다가왔습니다. "아, HTTPS 인증서를 아직 적용하지 않았네요. ACM을 사용하면 5분이면 해결할 수 있어요." 그렇다면 **ACM**이란 정확히 무엇일까요? 쉽게 비유하자면, ACM은 마치 자동차 보험을 관리해주는 시스템과 같습니다. 보험 가입 신청을 하면 자격을 확인하고, 보험증을 발급해주고, 만료일이 다가오면 자동으로 갱신해줍니다. ACM도 마찬가지로 웹사이트의 보안 인증서를 발급하고, 검증하고, 자동으로 갱신해주는 역할을 담당합니다. **HTTPS가 없던 시절**에는 어땠을까요? 예전에는 웹사이트를 만들면 그냥 HTTP로 서비스했습니다. 하지만 사용자가 입력한 비밀번호나 개인정보가 평문으로 전송되어 누구나 가로챌 수 있었습니다. 해커들은 중간에서 데이터를 훔쳐보는 공격을 손쉽게 할 수 있었습니다. 이런 문제를 해결하기 위해 **SSL/TLS 인증서**가 등장했습니다. 하지만 인증서를 발급받으려면 비용을 지불해야 했고, 매년 갱신해야 했으며, 설정도 복잡했습니다. 많은 개발자들이 인증서 만료로 인한 장애를 경험했습니다. 바로 이런 문제를 해결하기 위해 **AWS Certificate Manager**가 등장했습니다. ACM을 사용하면 **무료로 인증서를 발급**받을 수 있습니다. AWS 리소스(ALB, CloudFront 등)에서 사용하는 퍼블릭 인증서는 완전히 무료입니다. 또한 **자동 갱신** 기능으로 인증서 만료 걱정이 없습니다. 무엇보다 **간편한 통합**이라는 큰 이점이 있습니다. 클릭 몇 번으로 로드밸런서나 CloudFront에 인증서를 적용할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 ACM 클라이언트를 생성합니다. **region_name**을 'us-east-1'로 지정한 점이 중요합니다. CloudFront에서 사용할 인증서는 반드시 버지니아 북부 리전에서 발급받아야 하기 때문입니다. 다음으로 list_certificates 함수로 발급된 인증서 목록을 조회합니다. 상태 필터를 사용하여 발급 완료된 인증서와 검증 대기 중인 인증서만 가져옵니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 웹사이트를 운영한다고 가정해봅시다. 고객들이 결제 정보를 입력하는 페이지에서는 반드시 HTTPS를 사용해야 합니다. ACM으로 인증서를 발급받고 Application Load Balancer에 적용하면, 모든 트래픽이 암호화되어 안전하게 전송됩니다. 카카오페이, 네이버페이 같은 대형 서비스들도 이런 방식으로 고객 데이터를 보호하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **리전을 잘못 선택하는 것**입니다. ALB용 인증서는 해당 리전에서 발급받아야 하지만, CloudFront용 인증서는 반드시 us-east-1에서 발급받아야 합니다. 리전을 잘못 선택하면 인증서를 다시 발급받아야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 AWS 콘솔에서 ACM 서비스를 선택하면 되는 거군요!" ACM을 제대로 이해하면 보안이 강화된 웹사이트를 쉽게 운영할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - CloudFront에서 사용할 인증서는 반드시 us-east-1 리전에서 발급받으세요 - 와일드카드 인증서(*.example.com)를 사용하면 모든 서브도메인에서 사용할 수 있습니다 - ACM은 AWS 리소스에서만 사용 가능하며, EC2 인스턴스에 직접 설치는 불가능합니다 --- ## 2. 퍼블릭 인증서 요청 김개발 씨가 ACM 콘솔에 처음 접속했습니다. "인증서 요청" 버튼을 클릭했지만, 어떤 옵션을 선택해야 할지 막막했습니다. 퍼블릭 인증서와 프라이빗 인증서, 어떤 차이가 있을까요? **퍼블릭 인증서**는 외부 사용자가 접근하는 웹사이트에서 사용하는 인증서입니다. 마치 공공기관에서 발급받는 공식 신분증과 같습니다. 인터넷에 공개된 도메인에 대해 무료로 발급받을 수 있으며, 브라우저가 자동으로 신뢰하는 인증서입니다. 다음 코드를 살펴봅시다. ```python import boto3 # ACM 클라이언트 생성 acm_client = boto3.client('acm', region_name='ap-northeast-2') # 퍼블릭 인증서 요청 response = acm_client.request_certificate( DomainName='example.com', # 서브도메인도 함께 보호 SubjectAlternativeNames=[ 'example.com', 'www.example.com', '*.example.com' # 와일드카드로 모든 서브도메인 포함 ], ValidationMethod='DNS' # DNS 검증 방식 ) print(f"인증서 ARN: {response['CertificateArn']}") ``` 김개발 씨는 회사 홈페이지 www.mycompany.com에 HTTPS를 적용하려고 합니다. ACM 콘솔을 열어보니 "퍼블릭 인증서 요청"과 "프라이빗 인증서 요청" 두 가지 옵션이 보였습니다. 박시니어 씨가 옆에서 말했습니다. "외부 사용자가 접속하는 사이트라면 퍼블릭 인증서를 선택하세요. 완전히 무료예요." 그렇다면 **퍼블릭 인증서**란 정확히 무엇일까요? 쉽게 비유하자면, 퍼블릭 인증서는 마치 여권과 같습니다. 정부에서 발급한 공식 신분증이며, 전 세계 어디서나 인정받습니다. 공항 직원들은 여권을 보고 신원을 확인합니다. 마찬가지로 브라우저는 퍼블릭 인증서를 보고 웹사이트의 신원을 확인하고 자동으로 신뢰합니다. **인증서가 없던 시절**에는 어떤 문제가 있었을까요? HTTP로만 통신하던 시절에는 모든 데이터가 평문으로 전송되었습니다. 카페에서 공용 와이파이를 사용할 때, 같은 네트워크에 있는 누군가가 여러분의 비밀번호를 가로챌 수 있었습니다. 실제로 2000년대 초반에는 이런 방식의 해킹 사고가 빈번했습니다. 더 큰 문제는 **신뢰성**이었습니다. 접속한 웹사이트가 진짜인지, 가짜 사이트는 아닌지 확인할 방법이 없었습니다. 피싱 사이트가 정상 사이트를 흉내 내도 사용자는 구분할 수 없었습니다. 바로 이런 문제를 해결하기 위해 **SSL/TLS 퍼블릭 인증서**가 등장했습니다. 퍼블릭 인증서를 사용하면 **암호화 통신**이 가능해집니다. 브라우저와 서버 사이의 모든 데이터가 암호화되어 중간에서 가로채도 내용을 알 수 없습니다. 또한 **도메인 검증**도 얻을 수 있습니다. 인증 기관이 도메인 소유권을 확인하므로, 가짜 사이트를 만들 수 없습니다. 무엇보다 **브라우저 신뢰**라는 큰 이점이 있습니다. 주소창에 자물쇠 아이콘이 표시되어 사용자에게 안전함을 알려줍니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **DomainName**으로 메인 도메인을 지정합니다. 이것이 인증서의 주체가 됩니다. 다음으로 **SubjectAlternativeNames**에서 추가 도메인들을 나열합니다. www가 붙은 도메인과 와일드카드를 함께 지정하면 하나의 인증서로 모든 서브도메인을 보호할 수 있습니다. **ValidationMethod**는 'DNS'로 설정하는 것이 일반적입니다. 이메일 검증보다 자동화하기 쉽고 관리가 편리하기 때문입니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 운영한다고 가정해봅시다. shop.example.com, api.example.com, admin.example.com 등 여러 서브도메인을 사용합니다. 이때 *.example.com 와일드카드 인증서 하나를 발급받으면 모든 서브도메인에서 사용할 수 있습니다. 쿠팡이나 마켓컬리 같은 대형 이커머스도 이런 방식으로 인증서를 관리합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **도메인 표기를 잘못하는 것**입니다. example.com과 www.example.com은 서로 다른 도메인입니다. 둘 다 사용한다면 SubjectAlternativeNames에 모두 포함해야 합니다. 하나만 지정하면 다른 도메인에서는 인증서 오류가 발생합니다. 또 다른 실수는 **와일드카드의 범위를 오해하는 것**입니다. *.example.com은 한 단계 서브도메인만 커버합니다. api.example.com은 보호되지만, v1.api.example.com은 보호되지 않습니다. 두 단계 서브도메인이 필요하면 별도로 추가해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 실행한 김개발 씨는 인증서 ARN을 받았습니다. "이제 검증만 하면 되는 거죠?" 퍼블릭 인증서 요청을 제대로 이해하면 여러 도메인을 효율적으로 관리할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 와일드카드 인증서(*.example.com)를 사용하면 서브도메인 추가 시 인증서를 다시 발급받지 않아도 됩니다 - DNS 검증이 이메일 검증보다 자동화하기 쉽고 관리가 편리합니다 - 인증서 요청 후 72시간 내에 검증을 완료하지 않으면 자동으로 만료됩니다 --- ## 3. DNS 검증 인증서를 요청한 김개발 씨는 "검증 보류 중" 상태를 보고 당황했습니다. 박시니어 씨가 말했습니다. "도메인이 정말 네 거라는 걸 증명해야 해요. Route 53에 CNAME 레코드를 추가하면 됩니다." **DNS 검증**은 도메인 소유권을 증명하는 과정입니다. 마치 집 주소로 우편물을 받아서 본인 확인을 하는 것과 같습니다. ACM이 제공하는 CNAME 레코드를 DNS에 추가하면, AWS가 자동으로 확인하고 인증서를 발급합니다. 다음 코드를 살펴봅시다. ```python import boto3 acm_client = boto3.client('acm', region_name='ap-northeast-2') route53_client = boto3.client('route53') # 인증서 상세 정보 조회 cert_arn = 'arn:aws:acm:ap-northeast-2:123456789012:certificate/abcd-1234' cert_details = acm_client.describe_certificate(CertificateArn=cert_arn) # DNS 검증 레코드 가져오기 for domain in cert_details['Certificate']['DomainValidationOptions']: record = domain['ResourceRecord'] print(f"Name: {record['Name']}") print(f"Value: {record['Value']}") # 이 값들을 Route 53에 CNAME 레코드로 추가해야 합니다 ``` 김개발 씨가 인증서를 요청한 지 10분이 지났지만, 여전히 "검증 보류 중" 상태입니다. "뭔가 잘못된 건가?" 걱정이 되기 시작했습니다. 박시니어 씨가 화면을 보며 설명했습니다. "아직 도메인 소유권을 증명하지 않았잖아요. 누구나 다른 사람의 도메인으로 인증서를 요청할 수 있으니까, 진짜 주인인지 확인하는 절차가 필요해요." 그렇다면 **DNS 검증**이란 정확히 무엇일까요? 쉽게 비유하자면, DNS 검증은 마치 우편물로 본인 확인을 하는 것과 같습니다. 은행에서 카드를 발급할 때 등록된 주소로 우편물을 보냅니다. 그 우편물을 받을 수 있다면 그 주소의 실제 거주자라는 증거가 됩니다. 마찬가지로 ACM은 특정 DNS 레코드를 추가하라고 요청합니다. 그 레코드를 추가할 수 있다면 그 도메인의 실제 소유자라는 증거가 됩니다. **검증이 없다면** 어떤 일이 벌어질까요? 만약 누구나 아무 도메인에 대해 인증서를 발급받을 수 있다면 큰 문제가 생깁니다. 해커가 naver.com 인증서를 발급받아 가짜 네이버 사이트를 만들 수 있습니다. 사용자들은 자물쇠 아이콘을 보고 안심하겠지만, 실제로는 피싱 사이트입니다. 이런 사태를 방지하기 위해 반드시 도메인 소유권을 검증해야 합니다. 바로 이런 보안 문제를 해결하기 위해 **DNS 검증 방식**이 등장했습니다. DNS 검증을 사용하면 **자동화**가 가능해집니다. 한번 CNAME 레코드를 추가하면 인증서가 자동 갱신될 때도 같은 레코드를 사용합니다. 또한 **빠른 처리**도 얻을 수 있습니다. 이메일 검증은 메일을 확인해야 하지만, DNS 검증은 레코드 추가 후 몇 분이면 완료됩니다. 무엇보다 **보안성**이라는 큰 이점이 있습니다. DNS를 관리할 수 있다는 것은 도메인의 실제 소유자라는 강력한 증거입니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **describe_certificate**로 인증서 상세 정보를 가져옵니다. 여기에는 검증에 필요한 DNS 레코드 정보가 포함되어 있습니다. 다음으로 **DomainValidationOptions**를 순회하면서 각 도메인별 검증 레코드를 확인합니다. **ResourceRecord**에 CNAME의 이름과 값이 들어있습니다. 이 정보를 Route 53이나 다른 DNS 서비스에 추가하면 됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 스타트업에서 새로운 서비스를 런칭한다고 가정해봅시다. newservice.mycompany.com 도메인으로 서비스를 오픈하려고 합니다. 인증서를 요청하고 ACM 콘솔에서 CNAME 레코드 정보를 확인합니다. Route 53 콘솔로 이동하여 해당 레코드를 추가하면, 5분 안에 검증이 완료되고 인증서가 발급됩니다. 토스나 당근마켓 같은 회사들도 신규 서비스 런칭 시 이런 방식을 사용합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **CNAME 레코드를 잘못 추가하는 것**입니다. ACM이 제공한 이름과 값을 정확히 복사해야 합니다. 한 글자라도 틀리면 검증이 실패합니다. 특히 끝에 붙는 점(.)을 빼먹거나 추가하는 실수가 많습니다. 또 다른 실수는 **DNS 전파 시간을 고려하지 않는 것**입니다. CNAME 레코드를 추가한 후 전 세계 DNS 서버에 전파되기까지 시간이 걸립니다. 보통 몇 분이면 되지만, 경우에 따라 최대 48시간까지 걸릴 수 있습니다. 조급하게 "왜 안 되지?"라고 생각하기보다는 여유를 가지고 기다려야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. Route 53에 CNAME 레코드를 추가한 김개발 씨는 5분 후 "발급됨" 상태를 확인했습니다. "와, 이렇게 쉽게 되네요!" DNS 검증을 제대로 이해하면 인증서 발급을 자동화하고 안전하게 관리할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - Route 53 사용 시 ACM 콘솔에서 "Route 53에서 레코드 생성" 버튼을 클릭하면 자동으로 추가됩니다 - CNAME 레코드는 인증서가 자동 갱신될 때도 사용되므로 절대 삭제하지 마세요 - 외부 DNS 서비스 사용 시 TTL을 낮게 설정하면 검증 속도가 빨라집니다 --- ## 4. 인증서 갱신 6개월 후, 김개발 씨는 갑자기 걱정이 되었습니다. "인증서 만료일이 다가오는데, 어떻게 갱신하지?" 박시니어 씨가 웃으며 말했습니다. "ACM은 자동으로 갱신되니까 걱정 마세요." **ACM 인증서 자동 갱신**은 만료 60일 전부터 시작되는 자동화된 프로세스입니다. 마치 자동이체로 보험료가 갱신되는 것처럼, DNS 검증 레코드가 유지되고 있으면 ACM이 알아서 갱신합니다. 수동 작업이 필요 없어 인증서 만료로 인한 장애를 예방할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta acm_client = boto3.client('acm', region_name='ap-northeast-2') # 모든 인증서 조회 certificates = acm_client.list_certificates(CertificateStatuses=['ISSUED']) # 만료일 확인 for cert_summary in certificates['CertificateSummaryList']: cert_arn = cert_summary['CertificateArn'] cert_detail = acm_client.describe_certificate(CertificateArn=cert_arn) not_after = cert_detail['Certificate']['NotAfter'] days_remaining = (not_after - datetime.now(not_after.tzinfo)).days print(f"도메인: {cert_detail['Certificate']['DomainName']}") print(f"만료일: {not_after.strftime('%Y-%m-%d')}") print(f"남은 기간: {days_remaining}일") print(f"갱신 상태: {cert_detail['Certificate'].get('RenewalEligibility', 'N/A')}") print("---") ``` 6개월이 지난 어느 날, 김개발 씨는 갑자기 불안해졌습니다. 예전에 개인 프로젝트에서 Let's Encrypt 인증서를 사용했다가 갱신을 깜빡해서 웹사이트가 다운된 적이 있었습니다. "우리 회사 사이트 인증서는 언제 만료되지?" 급하게 ACM 콘솔을 확인했습니다. 만료일이 3개월 후로 표시되어 있었지만, 상태는 여전히 "발급됨"이었습니다. 박시니어 씨가 커피를 마시며 말했습니다. "ACM은 자동으로 갱신되니까 신경 쓸 필요 없어요. DNS 검증 레코드만 그대로 두면 됩니다." 그렇다면 **ACM 자동 갱신**은 정확히 어떻게 작동할까요? 쉽게 비유하자면, 자동 갱신은 마치 Netflix 구독과 같습니다. 매달 결제일이 되면 자동으로 결제되고 서비스가 계속 유지됩니다. 여러분이 할 일은 결제 수단(여기서는 DNS 레코드)이 유효한지만 확인하면 됩니다. 나머지는 시스템이 알아서 처리합니다. **수동 갱신이 필요했던 시절**에는 어떤 문제가 있었을까요? 전통적인 SSL 인증서는 1년마다 수동으로 갱신해야 했습니다. 달력에 표시해두고, 만료 전에 인증 기관 웹사이트에 접속하여 갱신 절차를 진행해야 했습니다. 담당자가 퇴사하거나 휴가 중이면 갱신을 놓칠 수 있었습니다. 더 큰 문제는 **갱신 실패로 인한 서비스 장애**였습니다. 인증서가 만료되면 브라우저가 경고창을 띄우고, 많은 사용자들이 사이트 접속을 포기합니다. 실제로 2020년에 유명 금융 서비스가 인증서 만료로 수 시간 동안 서비스를 중단한 사례가 있었습니다. 바로 이런 문제를 해결하기 위해 **ACM 자동 갱신 시스템**이 설계되었습니다. ACM 자동 갱신을 사용하면 **완전한 자동화**가 가능해집니다. 만료 60일 전부터 ACM이 자동으로 갱신을 시도합니다. 또한 **무중단 갱신**도 얻을 수 있습니다. 새 인증서가 발급되면 연결된 AWS 리소스에 자동으로 적용되므로 서비스 중단이 없습니다. 무엇보다 **관리 부담 제로**라는 큰 이점이 있습니다. 한번 설정해두면 영구적으로 사용할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **list_certificates**로 발급된 모든 인증서를 가져옵니다. 각 인증서의 ARN을 사용하여 상세 정보를 조회합니다. **NotAfter** 필드에서 만료일을 확인할 수 있습니다. 현재 날짜와 비교하여 남은 기간을 계산합니다. **RenewalEligibility** 필드를 보면 자동 갱신이 가능한 인증서인지 확인할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 대규모 이커머스 플랫폼을 운영한다고 가정해봅시다. 수십 개의 도메인과 서브도메인을 사용하고 있습니다. 각각의 인증서 만료일을 일일이 관리하는 것은 불가능합니다. ACM 자동 갱신을 사용하면 모든 인증서가 자동으로 갱신되어 관리 부담이 크게 줄어듭니다. 쿠팡이나 11번가 같은 대형 플랫폼도 이런 방식으로 인증서를 관리합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **DNS 검증 레코드를 삭제하는 것**입니다. 도메인 정리 작업을 하다가 "이 CNAME은 뭐지?"하고 삭제해버리면, 자동 갱신이 실패합니다. 만료 60일 전부터 갱신을 시도하므로, 갱신 실패 알림을 받으면 즉시 DNS 레코드를 복구해야 합니다. 또 다른 실수는 **사용 중이지 않은 인증서를 방치하는 것**입니다. ACM 인증서는 무료이지만, 계정당 발급 가능한 개수에 제한이 있습니다(기본 2,048개). 더 이상 사용하지 않는 인증서는 삭제하여 정리하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 코드를 실행한 김개발 씨는 모든 인증서가 "ELIGIBLE" 상태임을 확인했습니다. "앞으로 갱신 걱정은 안 해도 되겠네요!" ACM 자동 갱신을 제대로 이해하면 인증서 관리에서 완전히 자유로워질 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 만료 45일, 30일, 15일 전에 갱신 실패 시 이메일 알림이 발송되므로 AWS 계정 이메일을 정기적으로 확인하세요 - DNS 검증 레코드는 절대 삭제하지 마세요. 자동 갱신에 필수적입니다 - CloudWatch Events로 갱신 실패 알림을 Slack이나 SNS로 전송하도록 설정할 수 있습니다 --- ## 5. ALB와 CloudFront 연동 드디어 인증서를 발급받은 김개발 씨는 이제 실제로 웹사이트에 적용해야 합니다. "ALB 설정 화면에 인증서 선택 메뉴가 있네요?" 박시니어 씨가 고개를 끄덕입니다. "맞아요. 클릭 몇 번이면 HTTPS가 활성화돼요." **ACM 인증서와 AWS 리소스 연동**은 발급받은 인증서를 실제 서비스에 적용하는 과정입니다. 마치 자동차 보험증을 차량에 등록하는 것과 같습니다. Application Load Balancer나 CloudFront 설정에서 인증서를 선택하기만 하면 HTTPS 통신이 활성화됩니다. 다음 코드를 살펴봅시다. ```python import boto3 # ELBv2 클라이언트 생성 (ALB 관리) elbv2_client = boto3.client('elbv2', region_name='ap-northeast-2') # HTTPS 리스너 생성 response = elbv2_client.create_listener( LoadBalancerArn='arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:loadbalancer/app/my-alb/1234567890abcdef', Protocol='HTTPS', Port=443, Certificates=[ { # ACM 인증서 ARN 지정 'CertificateArn': 'arn:aws:acm:ap-northeast-2:123456789012:certificate/abcd-1234' } ], DefaultActions=[ { 'Type': 'forward', 'TargetGroupArn': 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/my-targets/1234567890abcdef' } ] ) print(f"HTTPS 리스너 생성 완료: {response['Listeners'][0]['ListenerArn']}") ``` 김개발 씨는 드디어 인증서를 손에 쥐었습니다. 아니, 정확히는 ACM 콘솔에서 "발급됨" 상태를 확인했습니다. 이제 실제 웹사이트에 적용할 차례입니다. "근데 이걸 어떻게 서버에 설치하지?" 전통적인 방식으로 생각한 김개발 씨는 인증서 파일을 다운로드하려고 했습니다. 박시니어 씨가 말했습니다. "ACM 인증서는 다운로드할 수 없어요. 대신 AWS 리소스에서 바로 선택해서 사용합니다. 훨씬 편해요." 그렇다면 **ACM 인증서 연동**은 정확히 어떻게 작동할까요? 쉽게 비유하자면, 인증서 연동은 마치 호텔 키카드 시스템과 같습니다. 프론트에서 방 번호를 등록하면 키카드가 자동으로 해당 방 문을 열 수 있게 됩니다. 키를 복사하거나 직접 들고 다닐 필요가 없습니다. 마찬가지로 ACM 인증서도 ARN만 지정하면 AWS 리소스가 자동으로 인증서를 사용합니다. **인증서를 수동으로 설치하던 시절**에는 어떤 문제가 있었을까요? 전통적인 웹서버에서는 인증서 파일(.crt, .key)을 다운로드하여 서버에 업로드해야 했습니다. Nginx나 Apache 설정 파일을 수정하고, 웹서버를 재시작해야 했습니다. 서버가 여러 대라면 모든 서버에 동일한 작업을 반복해야 했습니다. 더 큰 문제는 **보안 위험**이었습니다. 프라이빗 키 파일이 서버에 저장되므로, 서버가 해킹당하면 인증서도 탈취될 수 있었습니다. 또한 인증서 갱신 시 모든 서버에서 파일을 교체하고 재시작해야 하는 번거로움이 있었습니다. 바로 이런 문제를 해결하기 위해 **AWS 리소스 통합 방식**이 설계되었습니다. ACM 통합 방식을 사용하면 **원클릭 적용**이 가능해집니다. 콘솔에서 인증서를 선택하기만 하면 즉시 HTTPS가 활성화됩니다. 또한 **중앙 집중식 관리**도 얻을 수 있습니다. 여러 ALB나 CloudFront 배포에서 같은 인증서를 공유하며, 갱신 시 모든 리소스에 자동 적용됩니다. 무엇보다 **프라이빗 키 보안**이라는 큰 이점이 있습니다. 키 파일이 서버에 노출되지 않아 탈취 위험이 없습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **create_listener**로 ALB에 HTTPS 리스너를 추가합니다. **Protocol**을 'HTTPS', **Port**를 443으로 설정하는 것이 표준입니다. **Certificates** 배열에 ACM 인증서의 ARN을 지정합니다. 여러 인증서를 추가하여 SNI(Server Name Indication)를 지원할 수도 있습니다. **DefaultActions**는 HTTPS 요청을 어느 대상 그룹으로 전달할지 정의합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 마이크로서비스 아키텍처로 구성된 서비스를 운영한다고 가정해봅시다. api.example.com은 ALB를 통해 백엔드 서비스로 라우팅하고, www.example.com은 CloudFront를 통해 정적 콘텐츠를 제공합니다. 같은 와일드카드 인증서를 두 리소스에 모두 연결하면 일관된 보안을 유지할 수 있습니다. 배달의민족이나 야놀자 같은 서비스도 이런 아키텍처를 사용합니다. **CloudFront 연동**도 비슷한 방식으로 진행됩니다. CloudFront 배포 설정에서 "Custom SSL Certificate" 옵션을 선택하고 ACM 인증서를 지정합니다. 단, CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받아야 한다는 점을 기억하세요. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **HTTP to HTTPS 리디렉션을 설정하지 않는 것**입니다. HTTPS 리스너만 추가하면 http://example.com으로 접속한 사용자는 연결 실패를 경험합니다. HTTP 리스너에 리디렉션 규칙을 추가하여 모든 트래픽을 HTTPS로 전환해야 합니다. 또 다른 실수는 **보안 정책을 잘못 선택하는 것**입니다. ALB의 보안 정책은 지원하는 TLS 버전과 암호화 스위트를 정의합니다. 너무 오래된 정책을 사용하면 보안에 취약하고, 너무 최신 정책을 사용하면 구형 브라우저가 접속할 수 없습니다. 일반적으로 ELBSecurityPolicy-TLS-1-2-2017-01 정책을 권장합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. ALB에 인증서를 연결한 김개발 씨는 https://www.mycompany.com으로 접속했습니다. 주소창에 자물쇠 아이콘이 떴습니다. "드디어 HTTPS가 적용됐어요!" ACM 인증서 연동을 제대로 이해하면 안전하고 확장 가능한 웹 인프라를 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - ALB에서 HTTP(80) 리스너에 HTTPS(443)로 리디렉션 규칙을 추가하여 모든 트래픽을 보호하세요 - CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받아야 합니다 - SNI를 사용하면 하나의 ALB에서 여러 도메인에 대한 서로 다른 인증서를 사용할 수 있습니다 --- ## 6. 프라이빗 인증서 며칠 후 김개발 씨는 새로운 요구사항을 받았습니다. "내부 직원들만 사용하는 관리자 시스템에도 HTTPS를 적용해야 해요." 박시니어 씨가 설명했습니다. "외부에 공개되지 않은 도메인은 프라이빗 인증서를 사용해야 해요." **프라이빗 인증서**는 조직 내부에서만 사용하는 인증서입니다. 마치 사내 ID 카드처럼 외부에서는 인정받지 못하지만 조직 내에서는 유효합니다. AWS Private Certificate Authority를 통해 발급하며, VPN이나 내부 API 통신 암호화에 사용됩니다. 다음 코드를 살펴봅시다. ```python import boto3 # ACM PCA 클라이언트 생성 acm_pca_client = boto3.client('acm-pca', region_name='ap-northeast-2') acm_client = boto3.client('acm', region_name='ap-northeast-2') # 프라이빗 CA ARN (이미 생성되어 있다고 가정) ca_arn = 'arn:aws:acm-pca:ap-northeast-2:123456789012:certificate-authority/abcd-1234' # 프라이빗 인증서 요청 response = acm_client.request_certificate( DomainName='internal.mycompany.local', SubjectAlternativeNames=[ 'internal.mycompany.local', 'admin.mycompany.local', '*.internal.mycompany.local' ], # 퍼블릭 인증서와 다르게 CA ARN 지정 CertificateAuthorityArn=ca_arn, # 검증 불필요 (프라이빗 CA가 직접 발급) ) print(f"프라이빗 인증서 ARN: {response['CertificateArn']}") ``` 며칠 후 김개발 씨는 새로운 프로젝트를 시작했습니다. 사내 직원들만 VPN으로 접속하는 관리자 시스템입니다. "이것도 HTTPS를 적용해야 하나요?" 박시니어 씨가 고개를 끄덕였습니다. "당연하죠. 내부 시스템이라고 해서 보안을 소홀히 하면 안 돼요. 하지만 퍼블릭 인증서는 사용할 수 없어요. 외부에 공개되지 않은 도메인이니까요." 그렇다면 **프라이빗 인증서**란 정확히 무엇일까요? 쉽게 비유하자면, 프라이빗 인증서는 마치 사내 ID 카드와 같습니다. 회사 건물 안에서는 출입증으로 사용할 수 있지만, 외부 은행이나 공공기관에서는 신분증으로 인정받지 못합니다. 마찬가지로 프라이빗 인증서는 조직 내부에서는 유효하지만, 일반 브라우저는 신뢰하지 않습니다. **내부 시스템에 보안이 없던 시절**에는 어떤 문제가 있었을까요? 많은 기업들이 "어차피 내부망이니까 HTTP로 충분하다"고 생각했습니다. 하지만 내부자 위협이나 악성코드 감염 시 민감한 데이터가 그대로 노출되었습니다. 특히 원격 근무가 늘어나면서 VPN을 통한 내부 시스템 접속이 증가했고, 암호화되지 않은 통신은 큰 보안 구멍이 되었습니다. 더 큰 문제는 **규정 준수**였습니다. ISMS-P, ISO 27001 같은 정보보호 인증을 받으려면 내부 시스템도 암호화 통신을 사용해야 합니다. 감사 시 HTTP 통신이 발견되면 지적 사항으로 기록됩니다. 바로 이런 문제를 해결하기 위해 **프라이빗 인증서 시스템**이 등장했습니다. 프라이빗 인증서를 사용하면 **내부 통신 암호화**가 가능해집니다. 직원 노트북과 내부 서버 사이의 모든 데이터가 암호화됩니다. 또한 **유연한 도메인 관리**도 얻을 수 있습니다. .local, .internal 같은 공개되지 않은 도메인도 사용할 수 있습니다. 무엇보다 **완전한 제어권**이라는 큰 이점이 있습니다. 조직이 직접 인증 기관을 운영하므로 발급, 갱신, 폐기를 자유롭게 관리할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **acm-pca** 클라이언트로 Private Certificate Authority를 관리합니다. **ca_arn**은 미리 생성해둔 프라이빗 CA의 ARN입니다. **request_certificate**에서 **CertificateAuthorityArn**을 지정하는 것이 핵심입니다. 이 필드가 있으면 프라이빗 인증서로 발급됩니다. 퍼블릭 인증서와 달리 **ValidationMethod**가 필요 없습니다. 프라이빗 CA가 직접 발급하므로 도메인 검증 과정이 생략됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 금융 회사에서 내부 직원들이 사용하는 리스크 관리 시스템을 운영한다고 가정해봅시다. risk.internal.mybank.local 도메인으로 서비스하며, VPN 접속자만 사용할 수 있습니다. 프라이빗 인증서를 발급받아 내부 ALB에 적용하면, 직원들의 브라우저와 서버 사이 통신이 암호화됩니다. 또한 마이크로서비스 간 API 통신에도 mTLS(상호 TLS 인증)를 적용하여 보안을 강화할 수 있습니다. **Private CA 운영 비용**을 알아야 합니다. 프라이빗 CA는 무료가 아닙니다. CA 하나당 월 400달러의 비용이 발생합니다. 따라서 소규모 조직에서는 비용 대비 효과를 신중히 검토해야 합니다. 인증서 발급 자체는 개당 0.75달러이므로 많은 인증서를 발급할수록 효율적입니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **클라이언트 신뢰 설정을 빠뜨리는 것**입니다. 프라이빗 인증서는 브라우저가 자동으로 신뢰하지 않습니다. 조직의 모든 클라이언트(직원 PC, 서버 등)에 프라이빗 CA의 루트 인증서를 설치해야 합니다. 이 작업을 하지 않으면 브라우저가 "신뢰할 수 없는 인증서" 경고를 표시합니다. 또 다른 실수는 **프라이빗 CA 관리를 소홀히 하는 것**입니다. CA의 프라이빗 키가 유출되면 전체 시스템의 보안이 무너집니다. CA는 반드시 안전하게 보관하고, 접근 권한을 엄격히 제한해야 합니다. AWS Private CA는 HSM(Hardware Security Module)을 사용하여 키를 보호하므로 안전합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 프라이빗 인증서를 발급받고 내부 ALB에 적용한 김개발 씨는 VPN으로 접속하여 테스트했습니다. 처음에는 경고가 떴지만, IT팀이 전사 PC에 루트 인증서를 배포한 후에는 자물쇠 아이콘이 정상적으로 표시되었습니다. "내부 시스템도 이제 안전하네요!" 프라이빗 인증서를 제대로 이해하면 조직의 전체 네트워크를 end-to-end로 암호화할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - Private CA는 월 400달러의 비용이 발생하므로, 소규모 조직은 Let's Encrypt 같은 대안을 고려하세요 - 프라이빗 CA의 루트 인증서를 모든 클라이언트에 배포해야 브라우저 경고가 사라집니다 - 마이크로서비스 간 mTLS 인증에 프라이빗 인증서를 활용하면 제로 트러스트 아키텍처를 구현할 수 있습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, ACM, SSL, Certificate, HTTPS

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

ACM 인증서 관리 완벽 가이드

목차

1. ACM이란 무엇인가?

2. 퍼블릭 인증서 요청

3. DNS 검증

4. 인증서 갱신

5. ALB와 CloudFront 연동

6. 프라이빗 인증서

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드