게임 서버의 불법 TLS 인증서: 방화벽이 놓치는 것을 Certificate Transparency 로그가 잡아내는 방법
핵심 요약
게임 서버의 불법 TLS 인증서를 탐지하세요. Certificate Transparency 로그 모니터링, SPKI 핑거프린팅, CAA 레코드 배포로 인가되지 않은 인증서 발급을 차단하는 실전 런북 가이드입니다. 방화벽이 놓치는 위협을 잡아내는 방법을 다룹니다.
지금 이 순간, 인터넷의 모든 도메인에 대해 발급된 모든 TLS 인증서를 기록하는 공개적이고 추가 전용(append-only) 로그가 존재합니다. 여러분의 도메인도 포함됩니다. 누군가 내일 Certificate Authority(CA)를 찾아가 api.yourgame.com에 대한 유효한 TLS 인증서 발급을 설득한다면, 그 인증서는 몇 분 안에 Certificate Transparency(CT) 로그에 나타날 것입니다. 유일한 질문은 여러분이 이를 알아차릴지 여부입니다.
대부분의 게임 개발자는 알아차리지 못합니다. 플레이어가 SSL 오류를 보고하거나, 침투 테스터가 문제를 지적하거나, 더 나쁘게는 악성 인증서가 플레이어와 로그인 엔드포인트 사이에 중간자(MITM) 프록시를 가능하게 해서 도난당한 인증 토큰이 암시장에 나타나기 시작할 때야 발견합니다.
이 글은 게임 백엔드 도메인에 대한 Certificate Transparency 로그 모니터링을 위한 런북(runbook)입니다. CT 로그가 실제로 무엇인지, 프로그래밍 방식으로 쿼리하는 방법, 자체 정기 갱신에서 발생하는 노이즈를 필터링하는 방법, 그리고 인가되지 않은 인증서 발급이 보안 사고로 이어지기 전에 잡아내는 알림 파이프라인 구축 방법을 다룹니다.
무엇이 문제인가: 게임 백엔드를 대상으로 한 인가되지 않은 TLS 인증서 발급
공개적으로 신뢰되는 Certificate Authority(CA)가 발급하는 모든 TLS 인증서는 최소 두 개의 공개 Certificate Transparency 로그에 기록되어야 합니다. 이는 2018년 4월 Chrome이 모든 새 인증서에 CT 포함을 요구하기 시작하면서 사실상 의무화되었습니다. Apple Safari도 유사한 요구사항을 도입했습니다. 로그에 기록되지 않은 인증서는 주요 브라우저에서 신뢰되지 않습니다.
CT 생태계는 잘못된 발급(mis-issuance) 을 탐지하기 위해 존재합니다. 즉, 요청자가 제어하지 않는 도메인에 대해 CA가 인증서를 발급하는 상황입니다. 게임 백엔드의 경우 위협 모델은 다음과 같습니다:
- 자격 증명 가로채기: 공격자가
auth.yourgame.com에 대한 유효한 인증서를 획득하고, 플레이어와 실제 인증 서버 사이에 프록시를 설치하여 로그인 토큰을 수집합니다. 플레이어 입장에서는 브라우저가 인증서를 신뢰하므로 연결이 정상적으로 보입니다. - API 사칭:
matchmaking.yourgame.com에 대한 인증서를 통해 악의적인 제3자가 TLS 연결을 종료하고 가짜 게임 로직을 주입하거나 플레이어를 스푸핑된 서버로 리다이렉트할 수 있습니다. - 재생(Replay) 및 다운그레이드 공격: 유효한 인증서를 손에 넣은 공격자는 TLS를 제거하고 트래픽을 중계하여, 제대로 구성된 암호화 엔드포인트에서는 실패했을 세션 재생 또는 프로토콜 다운그레이드 공격을 가능하게 합니다.
이것은 이론적인 이야기가 아닙니다. CT 모니터링은 2015년 CNNIC MITM 사건과 Chrome이 모든 Symantec 인증서를 불신하게 만든 여러 건의 Symantec 잘못된 발급 사례를 잡아냈습니다. 국가 차원의 CA 침해를 잡아내는 동일한 메커니즘이 여러분의 인디 게임 API 서버에도 적용됩니다.
Certificate Transparency란 무엇인가 (그리고 무엇이 아닌가)
Certificate Transparency는 설치하는 보안 도구가 아닙니다. 참여 CA가 발급하는 모든 인증서를 기록하는 공개적으로 운영되고 암호학적으로 감사 가능한 로그 서버 집합입니다. 인증서가 발급될 때 일어나는 일은 다음과 같습니다:
- CA가 사전 인증서(pre-certificate) 를 생성하고 하나 이상의 CT 로그에 제출합니다.
- 각 로그는 Signed Certificate Timestamp(SCT) 를 반환합니다. 이는 로그가 인증서를 기록했다는 암호학적 약속입니다.
- CA는 해당 SCT를 최종 인증서에 내장하고 요청자에게 발급합니다.
- 브라우저는 유효한 SCT가 존재하는지 확인한 후 인증서를 신뢰합니다.
이러한 모든 로그 항목은 공개적으로 쿼리 가능합니다. crt.sh와 같은 서비스는 로그에 대한 무료 검색 인터페이스를 제공합니다. 여러분을 포함한 누구나 특정 도메인에 대해 발급된 모든 인증서를 검색할 수 있습니다.
CT가 하지 않는 것: CT는 잘못된 발급을 예방하지 않습니다. 나쁜 인증서를 폐기하지도 않습니다. CT는 예방이 아닌 탐지를 제공합니다. 즉, 누군가 실제로 로그를 모니터링하고 발견한 내용에 대해 조치를 취해야 합니다. 그 누군가는 바로 여러분입니다.
탐지 방법: CT 로그를 프로그래밍 방식으로 쿼리하기
Certificate Transparency 로그를 쿼리하는 가장 접근하기 쉬운 방법은 Sectigo가 운영하는 crt.sh Certificate Search를 통하는 것입니다. 인증이 필요 없는 JSON API를 제공합니다. 다음은 여러분의 도메인에 대한 CT 로그를 쿼리하고 예상치 못한 인증서 발급을 플래그하는 프로덕션 준비 완료 Python 스크립트입니다:
import requests
import json
from datetime import datetime, timedelta
# Domains to monitor — your game's API, auth, and matchmaker endpoints
MONITORED_DOMAINS = [
"api.yourgame.com",
"auth.yourgame.com",
"match.yourgame.com",
]
# Issuers you expect and trust (adjust to your CDN/infrastructure provider)
TRUSTED_ISSUERS = {
"C=US, O=Let's Encrypt, CN=R3",
"C=US, O=Let's Encrypt, CN=E1",
"C=US, O=Let's Encrypt, CN=R10",
"C=US, O=Cloudflare, Inc., CN=Cloudflare Inc ECC CA-3",
}
def query_ct_logs(domain: str, check_hours: int = 72) -> list[dict]:
"""Query crt.sh for certificates issued for a domain in the last N hours."""
url = f"https://crt.sh/?q=%25.{domain}&output=json"
headers = {"User-Agent": "GameBackend-CT-Monitor/1.0"}
try:
resp = requests.get(url, headers=headers, timeout=60)
resp.raise_for_status()
certificates = resp.json()
except requests.RequestException as e:
print(f"[ERROR] Failed to query crt.sh for {domain}: {e}")
return []
cutoff = datetime.utcnow() - timedelta(hours=check_hours)
results = []
for cert in certificates:
# crt.sh returns not_before as "2024-01-15T09:00:00" UTC
try:
not_before = datetime.strptime(cert["not_before"], "%Y-%m-%dT%H:%M:%S")
except (ValueError, KeyError):
continue
if not_before > cutoff:
results.append({
"id": cert.get("id"),
"domain": cert.get("common_name"),
"issuer": cert.get("issuer_name"),
"not_before": cert.get("not_before"),
"not_after": cert.get("not_after"),
"serial_number": cert.get("serial_number"),
})
return results
def run_monitor():
"""Check all monitored domains and return unauthorized certificates."""
all_alerts = []
for domain in MONITORED_DOMAINS:
recent_certs = query_ct_logs(domain, check_hours=72)
for cert in recent_certs:
issuer = cert["issuer"]
# Normalize: crt.sh sometimes adds whitespace variants
issuer_normalized = issuer.strip()
is_trusted = any(
trusted in issuer_normalized for trusted in TRUSTED_ISSUERS
)
if not is_trusted:
all_alerts.append(cert)
print(
f"⚠️ ALERT: Unexpected certificate for {cert['domain']}\n"
f" Issuer: {issuer}\n"
f" Valid: {cert['not_before']} → {cert['not_after']}\n"
f" Serial: {cert['serial_number']}\n"
f" crt.sh ID: https://crt.sh/?q={cert['serial_number']}\n"
)
if not all_alerts:
print("✅ No unexpected certificates found across all monitored domains.")
return all_alerts
if __name__ == "__main__":
run_monitor()
이 스크립트를 cron 작업으로 12시간마다 실행하면 기본적이지만 효과적인 CT 모니터링 시스템을 갖추게 됩니다:
0 */12 * * * /usr/bin/python3 /opt/monitor/ct_monitor.py >> /var/log/ct_monitor.log 2>&1
이 스크립트가 잘하는 것
- crt.sh 쿼리 (무료, API 키 불필요, 합리적인 폴링 주기에서는 무제한)
- 발급 시간 기준 필터링으로 지난 72시간 동안의 인증서만 표시
- 알려진 발급자 허용 목록(allowlist) 대조로 예상치 못한 CA의 인증서 플래그
- 구조화된 출력을 생성하여 Slack, Discord, PagerDuty 또는 이메일로 파이프 가능
이 스크립트의 한계
허용 목록 방식은 모든 발급자를 사전에 알고 있을 때만 작동합니다. Let's Encrypt에서 ZeroSSL로 전환하면 오탐(false alarm)이 발생합니다. 또한 crt.sh는 지연 시간이 있습니다. 발급과 로그 표시 사이에 일반적으로 15분에서 몇 시간이 소요되며, crt.sh가 항목을 인덱싱하는 추가 시간도 필요합니다. 실시간 알림을 위해서는 직접 CT 로그 모니터링이 필요한데, 이는 훨씬 더 복잡합니다.
또한 노이즈 문제가 있으며, 이는 모니터링 모델을 거의 완전히 무너뜨릴 뻔했습니다.
노이즈 문제: 자체 인증서로 인한 알림 피로
대부분의 CT 모니터링 구성을 망가뜨리는 부분은 바로 여러분 자신의 정상적인 인증서에서 발생하는 노이즈입니다.
TLS 인증서는 설계상 수명이 짧습니다. 표준 Let's Encrypt 인증서는 90일 동안 유효하며 약 60일째에 자동 갱신됩니다. Cloudflare Universal SSL 인증서는 60일마다 갱신될 수 있습니다. 연간 약 6회입니다. CA/Browser Forum은 2029년까지 최대 인증서 수명을 47일로 단축하기로 투표했습니다. 이는 갱신 주기를 거의 두 배로 늘리게 됩니다.
이러한 모든 갱신이 CT 로그에 나타납니다. 모든 로그 항목이 모니터링 스크립트를 트리거합니다. 자동 인증서 갱신을 사용하는 게임 백엔드 도메인 3개를 운영 중이라면, 자체 인프라에서 도메인당 연간 18개의 알림이 발생합니다. 각각이 로그에서 '새' 인증서로 나타납니다.
한 Cloudflare 고객은 '완전히 정상적인 인증서 갱신으로 스팸을 받는 것에 지쳐서' 모든 사이트에서 CT 모니터링을 비활성화했다고 설명하면서, '결국에는 실제로 읽지도 않았습니다'라고 덧붙였습니다.
외부에서 구분할 수 없는 자동 갱신 스트림 속에 단 하나의 이상 징후 인증서가 묻혀 있는 상황에서, 시스템은 작동을 멈춥니다. 여러분이 직접 발급한 인증서에 대한 알림을 식별하고 억제하는 방법이 필요합니다.
해결책: SPKI 핑거프린팅으로 자체 인증서와 미지의 인증서 구분하기
Cloudflare는 최근 SubjectPublicKeyInfo(SPKI) 해시를 인증서 발급 및 CT 알림 시스템 전반에 걸친 일관된 식별자로 사용하여 이 문제를 대규모로 해결했습니다. 이 접근 방식은 모든 인프라에 일반화할 수 있으며, 자체 인증서 관리를 유지하는 게임 개발자도 동일한 기법을 채택할 수 있습니다.
단순 조회가 작동하지 않는 이유
첫 번째 직관은 발급된 인증서를 데이터베이스에 추적하고 일련번호나 핑거프린트를 CT 로그 항목과 대조하는 것입니다. 문제는 타이밍입니다:
- CA가 사전 인증서(pre-certificate) 를 생성하고 CT 로그에 제출합니다.
- CT 로그가 사전 인증서를 기록합니다.
- CA가 Signed Certificate Timestamps(SCT)를 최종 인증서에 내장합니다.
- CA가 최종 인증서를 로그에 기록합니다.
- CA가 최종 인증서를 여러분에게 전달합니다.
사전 인증서와 최종 인증서의 해시 핑거프린트는 약간 다릅니다. 최종 인증서에는 사전 인증서에 없던 SCT가 내장되어 있기 때문입니다. 모니터링 시스템이 CA가 최종 인증서를 주문 시스템에 전달하기 전에 CT 로그에서 사전 인증서 항목을 보게 되면, 대조할 레코드가 없습니다. 오탐이 발생합니다.
SPKI 해시: 모든 단계에서 나타나는 단일 식별자
SPKI 해시는 타이밍 문제를 해결합니다. 공개 키가 사전 인증서와 최종 인증서에서 동일하기 때문입니다. 공개 키는 인증서가 발급되기 전인 키 생성 시점에 생성되며 변경되지 않습니다.
식별자는 다음과 같습니다: spki_sha256 = SHA-256(DER-encoded SubjectPublicKeyInfo)
계산 방법은 다음과 같습니다:
from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
import hashlib
def compute_spki_sha256_from_pem(pem_data: str) -> str:
"""Compute spki_sha256 from any PEM-encoded certificate (pre-cert or final)."""
cert = x509.load_pem_x509_certificate(pem_data.encode("utf-8"))
spki_der = cert.public_key().public_bytes(
encoding=serialization.Encoding.DER,
format=serialization.PublicFormat.SubjectPublicKeyInfo,
)
return hashlib.sha256(spki_der).hexdigest()
def compute_spki_sha256_from_csr(csr_pem: str) -> str:
"""Compute spki_sha256 from a Certificate Signing Request (earliest possible point)."""
csr = x509.load_pem_x509_csr(csr_pem.encode("utf-8"))
spki_der = csr.public_key().public_bytes(
encoding=serialization.Encoding.DER,
format=serialization.PublicFormat.SubjectPublicKeyInfo,
)
return hashlib.sha256(spki_der).hexdigest()
SPKI 필터링을 적용한 모니터링 흐름
업데이트된 모니터링 아키텍처는 다음과 같이 작동합니다:
여러분 측 (인증서 발급):
- 각 인증서 주문에 대해 새 키페어를 생성합니다.
- CSR 또는 공개 키에서
spki_sha256을 계산합니다. - CA가 발급을 시작하기 전에 해시를 추적 데이터베이스에 즉시 저장합니다.
- 인증서 수명 기간에 안전 여유(예: 만료 후 30일)를 더한 기간 동안 해시를 보관합니다.
모니터링 측 (CT 로그 스캔):
- 여러분의 도메인에 대한 새 CT 로그 항목을 파싱합니다.
- 각 로그 항목에서 공개 키를 추출하고
spki_sha256을 계산합니다. - 추적 데이터베이스에서 해시를 조회합니다.
- 일치 항목 발견 → 이 인증서는 여러분의 인프라에서 발급된 것입니다. 알림을 억제합니다.
- 일치 항목 없음 → 이 인증서는 여러분의 시스템에서 발급되지 않았습니다. 알림을 발생시킵니다.
이렇게 하면 외부 CA의 진정으로 의심스러운 인증서를 놓치지 않으면서 자체 갱신으로 인한 오탐을 제거할 수 있습니다.
전체 런북: 게임 서버용 Certificate Transparency 모니터링 구축
사전 요구사항
- 게임 백엔드에서 사용하는 모든 도메인 및 서브도메인 목록 (CDN, 인증, 매치메이킹, 텔레메트리, 에셋 전송 포함)
requests및cryptography라이브러리가 설치된 Python 3.9+- 알림 엔드포인트 (Slack 웹훅, Discord 웹훅, 이메일 SMTP 또는 PagerDuty)
- 발급 시점에 SPKI 해시를 기록하기 위한 인증서 관리 시스템 접근 권한
1단계: 공격 표면 파악
모니터링을 시작하기 전에 도메인의 전체 인벤토리가 필요합니다. 하나라도 놓치면 해당 도메인은 모니터링되지 않은 채 남습니다. 일반적인 게임 백엔드 도메인은 다음과 같습니다:
api.yourgame.com— 메인 게임 APIauth.yourgame.com/login.yourgame.com— 인증 엔드포인트match.yourgame.com/lobby.yourgame.com— 매치메이킹 및 로비 서버cdn.yourgame.com/assets.yourgame.com— 정적 에셋 전송telemetry.yourgame.com— 분석 및 크래시 리포트status.yourgame.com— 상태 페이지 (별도 서비스인 경우가 많음)
와일드카드 도메인(예: *.yourgame.com)은 공격 표면을 더욱 확장합니다. 여러분의 도메인을 포함하는 모든 와일드카드 인증서는 잘못 발급될 경우 공격 벡터가 됩니다.
2단계: SPKI 해시 추적 설정
인증서 배포 파이프라인에 해시 기록을 통합합니다. 인증서가 요청되거나 생성될 때마다 SPKI 해시를 계산하고 저장합니다. 간단한 방법은 로컬 SQLite 데이터베이스 또는 공유 Redis 키를 사용하는 것입니다:
import sqlite3
from datetime import datetime, timezone
DB_PATH = "/opt/monitor/spki_hashes.db"
def init_db():
conn = sqlite3.connect(DB_PATH)
conn.execute("""
CREATE TABLE IF NOT EXISTS known_hashes (
spki_hash TEXT PRIMARY KEY,
domain TEXT NOT NULL,
recorded_at TEXT NOT NULL,
expires_at TEXT
)
""")
conn.commit()
conn.close()
def register_certificate(spki_hash: str, domain: str, expires_at: str):
conn = sqlite3.connect(DB_PATH)
conn.execute(
"INSERT OR REPLACE INTO known_hashes (spki_hash, domain, recorded_at, expires_at) VALUES (?, ?, ?, ?)",
(spki_hash, domain, datetime.now(timezone.utc).isoformat(), expires_at),
)
conn.commit()
conn.close()
def is_known_certificate(spki_hash: str) -> bool:
conn = sqlite3.connect(DB_PATH)
row = conn.execute(
"SELECT 1 FROM known_hashes WHERE spki_hash = ?", (spki_hash,)
).fetchone()
conn.close()
return row is not None
3단계: 알림 파이프라인 구축
CT 쿼리 스크립트와 SPKI 데이터베이스 확인을 결합합니다. CT 로그에 새 인증서가 나타나면:
- SPKI 해시를 계산합니다.
- 알려진 해시 데이터베이스와 대조합니다.
- 알 수 없는 경우 즉시 알림을 발생시킵니다.
- 알림 페이로드에 crt.sh 링크, 발급자, 유효 기간, 호스트네임을 포함합니다.
Slack 또는 Discord 웹훅으로 알림을 라우팅하는 것은 빠르게 설정할 수 있으며 팀에 즉각적인 가시성을 제공합니다:
import os
import requests
SLACK_WEBHOOK_URL = os.environ.get("SLACK_CT_WEBHOOK_URL")
def send_slack_alert(cert: dict):
if not SLACK_WEBHOOK_URL:
print("[WARN] No Slack webhook configured; alert not sent.")
return
payload = {
"text": (
f"🚨 *Unauthorized TLS Certificate Detected*\n"
f"*Domain:* {cert['domain']}\n"
f"*Issuer:* {cert['issuer']}\n"
f"*Valid:* {cert['not_before']} → {cert['not_after']}\n"
f"*CT Log Entry:* https://crt.sh/?q={cert['serial_number']}\n"
f"_Investigate immediately._"
)
}
requests.post(SLACK_WEBHOOK_URL, json=payload, timeout=10)
4단계: 인시던트 대응 플레이북 정의
알림이 발생하면 문서화된 대응 절차가 필요합니다. 오탐은 5분의 조사 시간만 소요됩니다. 무시된 실제 잘못된 발급은 플레이어의 자격 증명을 잃게 만듭니다.
즉시 조치 (알림 발생 후 1시간 이내):
- crt.sh 링크를 열고 인증서 세부 정보(도메인, 발급자, 키 유형, 유효 날짜)를 확인합니다.
- 발급자가 인지하고 있는 곳인지 확인합니다. 여러분의
.com도메인에 대한 인증서를 발급하는 잘 알려지지 않은 지역 기관과 같은 알 수 없는 CA는 위험 신호입니다. - 인증서가 여전히 유효하고 도메인의 DNS 레코드에 대해 포트 443에서 연결 가능한지 확인합니다 (
openssl s_client -connect yourgame.com:443 -servername yourgame.com). - 인증서의 공개 키 핑거프린트를 알려진 정상 키와 비교합니다.
인증서가 인가되지 않은 경우:
- 발급 CA에 Certificate Problem Report를 제출합니다 (대부분의 CA는 abuse@ 또는 security@ 연락처를 보유).
- 동시에 CA의 웹 인터페이스 또는 직접 에스컬레이션 채널을 통해 CA에 연락합니다.
- 24시간 이내에 CA가 응답하지 않으면 CA/Browser Forum 또는 브라우저 공급업체의 루트 프로그램(Chrome의 Chromium Security 연락처, Mozilla의 CA Complaints)으로 에스컬레이션합니다.
- 잘못된 발급이 도메인 검증 실패(소유하지 않은 도메인의 소유권을 증명한 경우)였다면, 모든 DNS 및 WHOIS 레코드에서 침해 징후를 감사합니다.
- 도메인에 대한 인증서를 발급할 수 있는 CA를 제한하기 위해 CAA(Certificate Authority Authorization) DNS 레코드 배포를 고려합니다:
yourgame.com. IN CAA 0 issue "letsencrypt.org"
yourgame.com. IN CAA 0 issuewild "letsencrypt.org"
yourgame.com. IN CAA 0 iodef "security@yourgame.com"
CAA 레코드는 규정을 준수하는 CA가 발급 전에 확인합니다. 규정을 준수하지 않는 CA를 막을 수는 없지만, 공격 표면을 크게 좁히고 CAA 레코드를 존중하는 CA의 잘못된 발급을 불가능하게 만듭니다.
5단계: 재발 방지 자동화
인시던트를 처리한 후에는 보안 태세를 강화합니다:
- 모든 게임 백엔드 도메인에 CAA 레코드를 배포합니다 (아직 없는 경우).
- DNS 공급자가 지원하는 경우 TLSA 레코드와 함께 DNS 기반 엔티티 인증(DANE) 을 활성화합니다. 이는 특정 인증서 키를 DNS 수준에서 도메인에 바인딩합니다.
- 자체 인증서 갱신 주기를 단축합니다. 수명이 짧은 인증서는 개인 키가 손상되었을 때의 피해 범위가 더 작습니다.
- 자체 인프라의 모든 인증서 발급 이벤트를 타임스탬프와 SPKI 해시와 함께 감사 추적 항목으로 기록합니다.
모범 사례: 게임 서버용 TLS 인증서 관리 강화
메인 API뿐만 아니라 게임에서 사용하는 모든 도메인을 모니터링합니다. 텔레메트리 엔드포인트, CDN 오리진, 분석 비콘, 스테이징 서버 모두 공격 표면입니다.
old-matchmaking.yourgame.com과 같은 잊혀진 서브도메인에 대해 발급된 인증서도 해당 도메인이 연결 가능한 어떤 것으로 해석된다면 여전히 가로채기에 사용될 수 있습니다.제어하는 모든 도메인에 CAA DNS 레코드를 배포합니다. 단일
CAA 0 issue "letsencrypt.org"레코드는 규정을 준수하는 CA에 다른 기관의 발급 요청을 거부하도록 지시합니다. 이는 전체 잘못된 발급 클래스를 차단하는 5분짜리 DNS 변경입니다. CAA 정책으로 인해 CA가 발급 요청을 거부할 때 이메일 알림을 받으려면iodef를 추가합니다.배포 후가 아닌 발급 시점에 자체 인증서의 SPKI 해시를 저장합니다. CA가 사전 인증서를 로그에 기록하고 시스템이 최종 인증서를 수신하는 사이의 창에서 오탐이 발생합니다. CSR이 제출되기 전인 키 생성 시점에 SPKI 해시를 기록하면 이 격차가 완전히 제거됩니다.
모니터링 주기를 인증서 갱신 주기보다 빠르게 설정합니다. 인증서가 60일마다 갱신되는 경우 CT 로그를 하루에 한 번 확인하면 최대 탐지 지연 시간이 24시간입니다. 인증 토큰이 가장 가치가 높은 대상인 프로덕션 게임 백엔드의 경우 이는 허용 가능하지만 이상적이지는 않습니다. crt.sh의 인덱싱 지연 시간을 고려할 때 6~12시간마다가 실용적인 최적 지점입니다.
CT 알림을 기존 인시던트 대응 채널에 통합합니다. 아무도 확인하지 않는 공유 받은 편지함으로 이메일을 보내는 CT 모니터링은 무용지물보다 나쁩니다. 잘못된 확신을 만들기 때문입니다. 온콜 팀이 서버 상태 알림을 위해 이미 모니터링하는 동일한 Slack 또는 Discord 채널로 알림을 라우팅합니다. (이는 일반적인 서버 크래시 프로토콜과는 다르지만, 대응 주기는 유사해야 합니다. 시간에 민감하고, 문서화되어 있으며, 소유권이 명확해야 합니다.)
horizOn이 인증서 관리를 처리하는 방법
SPKI 해시를 수동으로 추적하고, CT 로그를 쿼리하고, CAA 레코드를 배포하고, 인시던트 대응 플레이북을 유지하는 것은 실제 작업입니다. 소규모 팀의 경우 일반적으로 2-3주 분량의 인프라 엔지니어링입니다. horizOn은 게임 개발자를 위한 백엔드 플랫폼의 일부로 TLS 인증서 프로비저닝 및 갱신을 처리하므로, 플랫폼을 통해 발급된 인증서는 이미 내부적으로 추적됩니다. 모니터링 측면(예상치 못한 발급자에 대한 CT 로그 읽기)은 여전히 외부 도구가 필요하지만, 퍼즐의 절반인 어떤 인증서가 여러분의 것인지 아는 문제는 자동으로 해결됩니다.
게임 백엔드를 구축 중이고 인증서 관리, 갱신 자동화, SPKI 추적을 직접 구성하고 싶지 않다면, horizOn이 사전 구축된 기반을 제공하므로 PKI 배관 작업 대신 게임플레이 로직에 집중할 수 있습니다.
다음 단계
이 글의 스크립트부터 시작하세요. 오늘 게임 도메인을 대상으로 실행하여 인프라에 대한 CT 로그에 이미 무엇이 있는지 확인하세요. 과거 인증서의 양에 놀랄 수도 있습니다. 그리고 알림 자동화를 시작하기 전에 최소한 기준선이 어떤 모습인지 알게 될 것입니다. 그런 다음 SPKI 해시 추적을 추가하여 자체 갱신을 필터링하면, 실제로 중요한 것, 즉 여러분이 선택하지 않은 CA가 발급한 예상치 못한 인증서를 표면화하는 모니터링 시스템을 갖추게 됩니다.