Personal Study Notes

Akamai 학습 정리

웹·네트워크 기초부터 CDN, Delivery 상품, 보안, 트러블슈팅까지 정리한 개인 학습 노트

1웹 · 네트워크 기초

1.1도메인 구조

계층 (오른쪽 → 왼쪽이 상위)

• TLD (Top Level Domain): .com, .net, .kr
• Root(Apex) 도메인: naver.com — 도메인 판매 사이트에서 구매하는 단위
• Sub 도메인: www.naver.com, mail.naver.com — Root/Apex 도메인 앞에 붙는 것

Apex 도메인 제약

• DNS 표준상 apex에는 CNAME 사용 불가 (SOA/NS 레코드와 공존 불가)
• Akamai는 CNAME 기반 → apex를 그대로 Edge로 보낼 수 없음

해결책 2가지

• Akamai Edge DNS로 zone 위임 + Zone Apex Mapping
• apex를 서브도메인으로 301 Redirect

도메인 끝 . 표기 (FQDN)

• example.com. — 여기서 끝나는 절대 도메인
• example.com — 뒤에 검색 도메인이 자동으로 붙을 수 있음 (example.com.test.com)

1.2DNS 레코드

정의 — 네임 서버에 저장된 도메인의 세부 정보. 질의를 통해 확인 가능

주요 레코드

• A / AAAA: IPv4 / IPv6 주소
• CNAME: 다른 도메인 이름(별칭). apex 사용 불가
• NS: 해당 도메인을 관리하는 DNS 서버 안내 (root가 TLD를 안내하는 것과 동일 원리)
• TXT: 자유 형식 텍스트 저장, 도메인 소유자 검증에 사용
• SOA: zone 관리 정보 (권위 서버, 기본 TTL 등)
• PTR: 역방향 조회 (IP → 도메인), 메일 서버 신뢰도 검증

@   IN  SOA     ns1.example.com. admin.example.com. (
                2026081401 ; Serial (일련번호)
                3600       ; Refresh (새로고침 주기, 1시간)
                1800       ; Retry (재시도 주기, 30분)
                604800     ; Expire (만료 기간, 1주일)
                86400 )    ; Minimum TTL (기본 캐시 시간, 1일)

TTL

• 모든 레코드에 존재
• 짧을 때: 변경 사항 빠르게 전파 / DNS 조회 부하 상승 → 트래픽 유연 조정 시 사용
• 길 때: 위와 반대

관련 도구

• nslookup / dig — Akamai 작업 시 필수. 도메인이 언급되면 반드시 조회해볼 것 (Akamai와 연결되어있는지 확인)
• curl — origin 서버 상태 확인

1.3DNS 위임 · CNAME Chain

DNS 위임 (Delegation)

• 상위 zone 네임서버가 하위 구간의 관리 권한을 다른 네임서버에 넘김
• 질의 과정에서 "어디로 가라"를 알려주는 것이며, 그 "어디"가 NS 레코드 값

CNAME Chain

• CNAME이 가리키는 대상이 또 CNAME인 구조
• A/AAAA가 나올 때까지 계속 따라감
• Akamai 예시: 고객 도메인 → EHN → akamaiedge.net → Edge IP
• 체인이 길어지면 최초 DNS 조회 시간 증가. 다만 최적 Edge를 찾는 과정이라 전체 응답은 빨라짐

LDNS (Local DNS)

• 사용자와 가장 가까운 Edge를 판단하는 기준점이 되는 핵심 개념
• OOC (Out Of Country): LDNS 위치가 사용자 실제 지역을 벗어난 상태

1.4DNS Flow

CDN 미사용

CDN 사용

성능 관점 — 사이트 접속 시간에 DNS Lookup Time이 포함됨. 느려지면 사이트 성능 저하 → DNS 구성 방식도 설계 고려 대상

1.5HTTP / HTTPS 기본

• 웹 브라우저와 웹 서버 간 데이터를 주고받는 프로토콜
• 포트: HTTP 80, HTTPS 443

CDN 개입 시

• CDN 없음: Client → Server
• CDN 있음: Client → Edge → Origin (한 단계 증가)
• HTTP/TLS 전 과정을 C–E 구간, E–O 구간에서 각각 수행

1.6HTTP Method

• GET: 리소스 조회
• HEAD: GET과 동일하나 body 없이 헤더만
• POST: 데이터 전송(생성). 로그인, 폼 제출
• PUT: 리소스 전체 교체
• PATCH: 리소스 일부 수정
• DELETE: 리소스 삭제
• OPTIONS: 서버가 지원하는 Method 확인

Akamai 연관성

• 캐싱 여부가 Method와 직결
• Edge는 GET/HEAD만 캐싱 대상으로 인식 → 정적 콘텐츠(Image, CSS, JS)는 GET 요청 시 Edge 캐시 응답 가능
• 나머지 Method는 캐싱 없이 Origin으로 전달
• Property Manager의 Allow HTTP Methods 규칙으로 특정 메서드 차단/경로별 허용 제어

1.7HTTP Status Code

1xx (Information): 요청 수신, 처리 중

2xx (Success)

• 200 OK: 리소스 정상 반환
• 201 Created: 새 리소스 생성됨 (주로 POST 결과)
• 204 No Content: 처리 성공, 반환할 콘텐츠 없음 (예: DELETE 성공)

3xx (Redirection)

• 301 Moved Permanently: 영구 이전
• 302 Found: 임시 이동 (점검 페이지 등)
• 304 Not Modified: 캐시 재사용 가능 (보유 캐시가 최신인지 확인한 결과)

4xx (Client Error)

• 400 Bad Request: 요청 형식 자체가 잘못됨
• 401 Unauthorized: 인증 안 됨, 로그인 필요
• 403 Forbidden: 접근 권한 없음
• 404 Not Found: 리소스 없음

5xx (Server Error)

• 500 Internal Server Error: 원인 불명 서버 오류
• 502 Bad Gateway: 프록시/게이트웨이가 상위 서버로부터 잘못된 응답 수신
• 503 Service Unavailable: 일시적 과부하 또는 점검 중
• 504 Gateway Timeout: 상위 서버 응답 대기 중 시간 초과

Akamai 연관성

• 304: 캐시 유효성을 Origin에 확인한 결과
• 502: Edge가 Origin에 요청했으나 응답 없음 → Origin 다운, 방화벽 차단, 인증서 오류가 흔한 원인
• 504: Edge가 Origin 응답 대기 중 타임아웃 → 네트워크 지연이 주 원인
• 403: WAF 차단 시에도 403 반환 가능 → 리소스 부재인지 WAF 차단인지 구분 필요

1.8HTTP Header

HTTP 요청·응답에 부가 정보를 담아 전달

Request Header (Client → Server)

• Host: 어느 도메인으로 요청하는지
• User-Agent: 클라이언트 종류 (브라우저, curl, 봇)
• Cookie: 로그인 세션 등 상태 정보
• Authorization: 인증 토큰
• Accept: 원하는 응답 형식 (JSON, HTML)
• If-Modified-Since: 지난 응답 이후 변경 여부 확인

Response Header (Server → Client)

• Content-Type: 응답 형식 (text/html, application/json)
• Content-Length: 응답 본문 크기
• Set-Cookie: 클라이언트에 쿠키 저장 지시
• Cache-Control: 캐싱 방법·기간 지시
• Location: 리다이렉트 대상 주소

Akamai 연관성 — 캐싱 정책을 헤더로 제어 / 커스텀 헤더로 캐시 디버깅 가능 / Edge에서 헤더 추가·수정·삭제 가능 → Origin에 없는 보안 헤더를 Edge 단에서 삽입

1.9Host Header

• Request Header 중 하나, 요청 대상 도메인을 서버에 전달
• 형식: Host: www.example.com
• 필요 이유: 한 서버에 여러 도메인이 호스팅될 때 IP만으로는 구분 불가

Akamai 연관성

• Edge가 Property(어느 고객 설정)를 구분하는 기준
• Edge → Origin 구간에서 Host 헤더 변경 가능 (Property Manager)
• Forward Host Header: Edge가 Origin으로 요청 전달 시 Host Header를 무엇으로 채울지 지정하는 설정

1.10Cookie

• 서버가 클라이언트(브라우저)에 저장을 요청하는 데이터 조각
• HTTP는 상태를 기억하지 못하므로 쿠키가 상태 정보를 유지

동작 흐름

1. 서버가 Response에 Set-Cookie: session_id=abc123 전송
2. 브라우저가 저장
3. 이후 동일 도메인 요청마다 Cookie: session_id=abc123 자동 첨부

용도: 로그인 세션 유지, 장바구니, 개인화 설정

주요 속성

• Expires / Max-Age: 유효기간
• Secure: HTTPS 연결에서만 전송
• HttpOnly: JavaScript 접근 불가 (XSS 방어)
• SameSite: 타 사이트발 요청에 쿠키를 실을지 결정

Akamai 연관성

• 쿠키가 있으면 캐싱이 꼬일 수 있음
• Property Manager에서 캐시 키에 쿠키 포함 여부 결정
• 일반 구성: 정적 콘텐츠는 쿠키 무관 캐싱 / 로그인 기반 페이지는 쿠키 존재 시 캐싱 제외(bypass)
• Edge → Origin 구간 쿠키 전달 여부 설정 가능 (트래킹용 등 불필요 쿠키는 Edge에서 제거)
• 실사용: 이커머스에서 상품 상세(static)와 마이페이지(dynamic)를 경로별로 다른 캐싱 규칙 적용

1.11Cache-Control

Response Header 중 하나, 콘텐츠 캐싱 방법을 지시

주요 지시어

• max-age=3600: 1시간 동안 캐시 그대로 사용
• no-cache: 저장은 하되 매번 서버에 유효성 검증 후 사용
• no-store: 저장 금지
• private: 개별 사용자 브라우저에만 캐싱 허용, CDN·프록시 캐싱 금지
• public: CDN·프록시 캐싱 허용
• must-revalidate: 유효기간 경과 시 반드시 서버 재확인

Akamai 연관성

• Edge는 Origin의 Cache-Control을 참고해 캐싱
• Akamai가 Origin 지시를 덮어쓰기(Override) 가능
• private / no-store 응답은 원칙적으로 Edge가 캐싱하지 않으나 PM 설정으로 강제 캐싱 가능 → 개인화 페이지가 캐싱되는 원인 점검 포인트

1.12CORS (Cross-Origin Resource Sharing)

• 브라우저가 기본 차단하는 타 출처 요청을 서버가 명시적으로 허용하는 방식
• 출처(Origin) 정의: 프로토콜 + 도메인 + 포트가 모두 같아야 동일 출처

예시 — https://shop.com 페이지의 JS가 https://api.shop.com에 데이터 요청 → 도메인이 달라 서로 다른 출처로 취급

브라우저가 막는 이유 — 다른 출처로의 요청 결과 접근 차단이 기본값. 악성 사이트의 JS가 정보를 빼갈 수 있기 때문

허용 방식

• 응답 서버가 Access-Control-Allow-Origin: https://shop.com 헤더로 예외 허용
• 서버는 허용 헤더가 없어도 응답 자체는 보내지만, 브라우저가 CORS policy로 차단
• 보통 OPTIONS 메서드(Preflight)로 요청 가능 여부 확인 후 사용. API 호출 구조에서 주로 사용

Akamai 연관성 — Edge에서 CORS 응답 헤더 삽입·수정 가능 / Preflight(OPTIONS) 요청도 캐싱 대상이 될 수 있음

1.13Redirect

• 요청한 URL이 아닌 다른 URL로 자동 이동시키는 동작
• 구현: 301/302 상태코드 + Location: <새 주소> 응답 헤더 → 클라이언트가 자동 재요청

목적

• 도메인/URL 구조 변경 (영구 이전은 301)
• 프로토콜 강제 (http → https)
• www 유무 통일
• 지역·언어별 분리 (/kr, /us)
• 일시적 안내 (점검·프로모션 페이지, 302)

Akamai 연관성

• Origin 처리: 웹서버/애플리케이션이 직접 301·302 응답 (기본 방식)
• Edge 처리: Property Manager의 Redirect behavior로 Edge에서 즉시 응답

1.14Compression

• 클라이언트가 해제 가능한 압축 방식을 헤더에 명시
• 방식: gzip, br 등. 텍스트 기반 콘텐츠에서 효과 큼

헤더

• Request: Accept-Encoding: gzip | br
• Response: Content-Encoding: gzip | br

Akamai 연관성 — Origin이 압축하지 않아도 Edge가 압축 가능 / 캐시된 콘텐츠는 압축 여부에 따라 별도로 저장 가능 / 압축 대상 파일 자동화 설정 가능

1.15HTTP 버전별 특징

HTTP/1.1

• 가장 오래 쓰인 기본 버전
• 한 커넥션에서 요청을 순서대로 하나씩만 처리
• 브라우저가 TCP 커넥션을 병렬로 열어 우회

HTTP/2

• 멀티플렉싱: 하나의 TCP 커넥션에서 여러 요청·응답을 동시에 교환
• 커넥션을 병렬로 열 필요 없음
• 헤더 압축, 서버 푸시 기능 추가
• TCP 위에서 동작 → TCP 계층 자체의 문제는 그대로 존재

HTTP/3

• 전송 계층을 TCP → QUIC(UDP 기반)으로 변경
• HOL Blocking(Head of Line Blocking) 해결: TCP는 패킷 유실 시 뒤 데이터가 모두 대기. HTTP/2 멀티플렉싱으로도 회피 불가
• QUIC은 각 스트림이 독립적이라 패킷 유실이 다른 스트림에 영향 없음
• TLS를 자체 통합해 핸드셰이크가 동시에 처리됨

Akamai 연관성

• Edge는 Client 구간에서 HTTP/2·HTTP/3 지원, PM에서 활성화
• Edge–Origin 구간은 HTTP/1.1 또는 HTTP/2가 더 일반적 → 구간별로 버전이 다른 경우가 많음
• 모바일 환경(네트워크 전환 잦음, 패킷 유실 흔함)에서 HTTP/3 효과가 커 모바일 비중 높은 서비스가 우선 검토 대상

1.16TLS 인증서

역할

• 신원 증명: 해당 도메인의 진짜 서버인지 확인, 피싱 방지
• 암호화 통신 지원: 인증서 공개키로 세션키를 교환해 통신 암호화

동작 원리

• CA(Certificate Authority)라는 신뢰할 수 있는 제3자가 발급
• 인증서에는 공개키, 도메인 이름, 발급 CA, 유효기간이 담기고 CA가 자기 개인키로 서명
• 브라우저는 신뢰 CA 목록을 보유, 그중 하나의 서명이 있으면 신뢰
• TLS 핸드셰이크에서 인증서를 교환하고 공개키로 세션키를 주고받음

TLS 1.1 / 1.2 핸드셰이크

TLS 1.3 핸드셰이크

Akamai 연관성

• Edge는 TLS 1.3 지원, PM에서 허용 버전 설정 가능
• 인증서 보유 구조: Client–Edge 구간은 Akamai(Edge) 인증서 사용 / Edge–Origin 구간은 Origin이 제시한 인증서를 Edge가 사전 보유분과 대조 → Certificate Pinning

1.17SNI (Server Name Indication)

• TLS Handshake의 ClientHello에서, 암호화 전에 접속 대상 도메인을 미리 알려줌

필요 이유

• 하나의 IP에 여러 도메인이 서비스되는 가상 호스팅 환경에서 서버가 어떤 인증서를 줘야 할지 판단 불가
• 도메인 이름을 평문으로 실어 보내면 서버가 맞는 인증서를 선택해 응답

Host Header와의 차이

• Host Header: TLS 종료 후 암호화된 HTTP 요청 안에 포함 → 어떤 콘텐츠/설정을 적용할지 판단
• SNI: TLS 핸드셰이크 단계 → 어떤 인증서를 제시할지 판단

Akamai 연관성 — Edge가 어떤 Property로 라우팅할지 판단하는 첫 단서

1.18Proxy · Client IP

Forward Proxy — 클라이언트 IP를 가리는 역할. Client → Proxy → Destination 순으로 접근, 목적지에는 Proxy IP가 보임

Reverse Proxy — 서버(Origin IP)를 가리는 역할. Client는 Origin과 Proxy 중 누구와 통신하는지 구분 불가. Akamai가 Origin 은폐를 위해 사용하는 방식

Client IP 전달 문제

• CDN 사용 시 Origin에는 Edge IP만 찍힘
• Origin이 실제 사용자 IP를 알아야 하는 경우: 지역별 콘텐츠 차등 제공(Geo-blocking), 부정 로그인 탐지·로그 분석, Origin 단 Rate Limiting, Credential Stuffing 등 공격 탐지

해결 헤더

• XFF (X-Forwarded-For): 전송 경로상의 IP를 모두 전달
• True-Client-IP: Akamai 자체 제공 헤더, 최초 클라이언트 IP만 정확히 하나 전달

1.19API

• Program ↔ Program 간 통신 인터페이스
• 클라이언트 요청 수신 → 키 인증 → 데이터 처리 후 HTTP로 결과 반환

2CDN 핵심 개념

2.1CDN 구조

C – E – O 구조

• Client (사용자) – Edge (Akamai) – Origin (고객)
• 도메인 기반, 웹 기반 서비스가 대상
• CDN 진단 시 "도메인이 있는가"를 최우선 확인

CDN 도입 이점

• Origin 서버가 고스펙일 필요 없음
• Origin으로 가는 요청 자체가 줄어듦 (캐시 만료·미보유 건과 동적 콘텐츠만 처리)

• Akamai는 CNAME 기반으로만 동작
• Edge Hostname(EHN)을 만들어 고객 도메인의 CNAME에 등록
• "도메인이 Akamai에 타 있다" = CNAME 등록이 되어 있다는 뜻
• apex 도메인은 Edge DNS(Zone Apex Mapping) 또는 Redirect로만 연결 가능

2.2Akamai 트래픽 유입 전체 흐름

① DNS 조회 - CNAME Chain 추적

마지막 단계에서 GTM이 LDNS 기준 가장 가깝고 최적인 Edge IP 반환

② TCP 연결 및 TLS 핸드셰이크

• 클라이언트가 SNI로 도메인 전달, Edge가 해당 도메인 인증서 응답
• Edge가 Host Header로 어느 고객의 어느 Property인지 판단

③ 보안 검사 (설정 시) — WAF, Bot Manager 등이 있으면 Origin 이전에 Edge에서 요청 검사

④ 캐시 확인

• 캐시 보유 + 정적 콘텐츠 → Edge가 즉시 응답 (Cache HIT)
• 캐시 없음 또는 동적 콘텐츠 → Edge가 Origin과 세션을 맺고 응답을 받아 전달, 필요 시 캐싱

2.3Static / Dynamic 콘텐츠

• Static (캐싱 가능): Image, CSS/JS, Font, Video, Download File
• Dynamic (캐싱 불가 또는 제한적): 로그인/마이페이지, API 응답, 검색 결과, 결제/장바구니, 실시간 데이터(주식 등)

2.4캐싱

• Cache HIT: Edge가 해당 콘텐츠를 이미 보유하고 유효한 상태 → 즉시 응답
• Cache MISS: Edge에 없거나 유효기간 경과 → Origin에 재요청 후 응답, 캐시에 저장

Cache Key — Edge가 캐시를 저장할 때 사용하는 식별자. 예: /product?id=1 → Cache A / /product?id=2 → Cache B (별개 캐시)

HIT 조건 2가지

1. 요청이 저장된 캐시와 정확히 같은 항목을 가리킬 것 (Cache Key 매칭)
2. 캐시 유효기간이 지나지 않았을 것

쿼리 파라미터 — 도메인 뒤 ? 이후 문자열 (?v=20260727). 값별로 각각 캐싱 가능

2.5TTL

Edge가 콘텐츠를 얼마나 캐싱할지 지정. Origin·Edge 어느 쪽에서든 설정 가능, Akamai가 강제 지정(Override) 가능

TTL이 길 때 — HIT Ratio 상승, Origin 부하 감소, 응답 속도 빠름 / 콘텐츠 수정 반영에 시간 소요 / 정적 리소스에 주로 사용

TTL이 짧을 때 — 콘텐츠 최신성 유지 / MISS 잦아 Origin 부하 증가, 속도 이득 감소 / 동적 리소스에 주로 사용

2.6Purge

Edge 캐시를 TTL과 무관하게 강제 무효화

단위

• URL 단위: 특정 URL 하나만 지정
• CP Code 단위: CP Code로 묶인 범위 전체
• Cache Tag 단위: Origin이 응답 헤더에 붙인 태그 기준으로 관련 URL 일괄
• Directory / Extension 단위 (와일드카드) — 반영에 시간이 오래 걸림 (실무상 약 40분 소요 사례)

처리 방식

• Invalidate (무효화): 즉시 삭제하지 않고 "유효하지 않음" 표시. 다음 요청 시 Origin에 재확인 → 304 Not Modified면 재사용, 변경됐으면 새로 수신
• Delete: 캐시를 아예 삭제, 다음 요청은 무조건 MISS

2.7Origin Offload

전체 트래픽 중 Edge가 캐시로 처리해 Origin까지 가지 않은 비율

Origin Offload = (Cache HIT 요청 수) / (전체 요청 수) × 100

높이는 방법

• TTL을 최대한 길게 설정
• Cache Key를 단순하게 설정
• 캐싱 불가한 동적 콘텐츠는 DSA/ION 같은 동적 가속 상품으로 일부 캐싱

2.8CP Code (Content Provider Code)

• 트래픽을 분류·관리하는 단위로 쓰는 숫자 식별 코드
• 하나의 Property 안에서 콘텐츠를 성격별로 분리: 이미지/CSS/JS 등 정적 리소스, HTML 페이지, API 트래픽

그룹별로 가능한 것 — 트래픽/대역폭 리포트 분리 확인 / Billing 분리 산정 / Purge 수행

Property와 다대다 매핑 가능

2.9Edge Hostname · Property Hostname

Edge Hostname (EHN) — Akamai가 발급하는 중계용 도메인. Client DNS 질의가 EHN을 가리키게 해 GTM이 자동으로 Edge 서버를 지정

Property Hostname — www.example.com으로 오는 요청에 해당 Property 설정을 적용하는 기준 도메인. 하나의 Property에 여러 개 등록 가능

2.10Tier 구조 (2중 Edge)

구성: Client - Child Edge - Parent Edge - Origin

구간 명칭: First Mile / Middle Mile / Last Mile. 모든 링크는 ISP를 통해 연결

특징 — Child, Parent 둘 다 캐싱 수행 / Child Edge끼리는 캐시를 공유하지 않음

SureRoute (Adaptive Routing) — Middle Mile에서 여러 회선이 주기적으로(약 30분 간격) 경쟁해 가장 빠른 회선 선택. DSA 계열 상품에서 제공

2.11Property Manager (PM)

CDN 설정을 관리하는 도구

배포 환경

• Staging: 실 트래픽에 영향 없는 테스트 전용 Edge 네트워크. 설정을 먼저 배포해 검증
• Production: 검증 완료 후 실서비스 Edge 네트워크에 배포

버저닝 — 기존 버전으로 롤백 가능 → 버전 노트에 변경 내용 기록 필요

Rule 우선순위 — Default가 가장 낮음. 아래쪽에 배치된 Custom Rule일수록 우선 적용 (Priority 1이 최우선)

지원 포트 — 기본적으로 80/443 위주 (일부 예외 존재)

2.12Property 생성 절차 (DD 기준)

1. DOM(Domain Ownership Manager) 생성 → 도메인 소유 검증
2. CPS(인증서) 생성
3. Property 생성
   • 도메인 이름 입력
   • 그룹 선택 (같은 회사 내에서도 그룹이 달라질 수 있음)
   • Security Options - 인증서 선택: Standard(고객이 직접 인증서 발급받아 사용) / Shared(Akamai 도메인이 생성·노출되어도 무관한 고객용)
   • Modules: 고객 요구 기능이 모듈에서 지원되는지 확인 (상품별 무료/유료 상이)
4. Property Hostname 입력 (복수 가능), 인증서 선택 — CPS-Managed 선택 시 관리 주체 지정. 생성 시점에 인증서가 실제로 존재할 필요는 없음
5. Origin Server 설정 — Origin은 IP가 아닌 Hostname으로 지정 권장 (Origin 교체 시 DNS만 바꾸면 되므로 관리가 쉬움)
6. Staging 배포 → Production 배포

3Akamai Delivery 상품

3.1상품 체계

포함 관계: ION ⊃ DSA ⊃ Caching(DD, AMD)

DD (Download Delivery) — 정적 콘텐츠 중심: 일반 object, 이미지, 게임 다운로드 파일

AMD (Adaptive Media Delivery)

• DD와 동급의 캐싱 상품, 미디어·스트리밍에 최적화
• 영상을 청크로 쪼개 여러 해상도로 제공 → 유튜브식 화질 자동 전환
• 지원 포맷: HLS, HDS, MSS, MPEG-DASH, CMAF

DSA (Dynamic Site Accelerator)

• 캐싱 + 가속 (SureRoute)
• 동적 콘텐츠 가속, 가장 많이 사용
• B Map 사용, AAP를 적용할 수 있는 상품
• 단가 높음 — 대역폭/사용량 기준 과금, DD 대비 4~5배 수준 (고객별 상이)
• 도메인이 2개 이상이면 DSA/DD 혼용 가능 (예: www.abc.com은 DSA, img.abc.com은 DD)

ION

• DSA 업그레이드 버전, 성능 최적화 대표 솔루션
• R Map 사용 — 여유 있는 맵이라 빠르지만 비쌈
• Akamai Intelligent Edge Platform + 동적 콘텐츠 가속 결합

3.2ION 상세 기능

자동 성능 최적화

• Adaptive Acceleration — mPulse 기반, 개발 작업 거의 없이 자동 최적화
• Automatic Server Push: 브라우저 유휴 시 HTTP/2로 주요 리소스 미리 푸시
• Automatic Preconnect: 서드파티 콘텐츠로의 네트워크 연결 사전 수립
• Automatic Font Preload: 유휴 시간에 폰트 미리 다운로드
• Resource Optimizer: JS, CSS, 폰트 파일 압축·캐싱

Advanced Cache Optimization

• 기존 단순 캐싱으로는 동적·개인화 콘텐츠 캐싱이 어려움
• 세밀한 기준으로 캐시 규칙 분리: 쿼리 스트링, 캐시 키(커스터마이징), 사용자 위치, 네트워크 제공사/타입, 디바이스 특성
• 효과: 같은 조건의 사용자끼리 캐시 공유 → Origin 요청 감소, 응답 속도 향상

Compression — 파일 크기를 5~25% 수준으로 조절

콘텐츠 제어 — Script Management: 서드파티(광고, 분석) 스크립트 로딩 제어로 성능·보안 관리

개발 민첩성

• 기존 개발 워크플로우에 통합, 배포 속도 개선
• 기존에는 ACC에서 수동 클릭 설정 → PM API/Terraform으로 IaC 관리 가능
• Git에 설정 변경 이력을 남기고 CI/CD 파이프라인에서 자동 테스트·배포

기타 — 정책 기반 최적화, HTTP/3, 적응형 가속화, 실시간 콘텐츠 관리, DevOps 운영도구 제공

3.3Image & Video Manager (IVM)

웹사이트의 사진·비디오 품질을 자동 최적화하는 SaaS 솔루션

해결하는 문제 — 무거운 페이지, 느린 로딩 속도 / 모바일 접속 시 미디어 품질 저하

기능

• 지각 품질(Perceptual Quality) 기반 자동 최적화 — 시각적 품질 저하 없이 압축
• 사용자 디바이스에 맞춰 자동 최적화
• 예술적 요구를 충족하는 파생 이미지를 동적 생성
• 360도 화면, 고객 커스터마이징 지원
• 친숙한 UI, Open API 제공

지원 포맷: JPEG, GIF, PNG, BMP, TIFF / MOV, MP4

효과 — 웹사이트 로드 시간 단축, 일관된 UX / 저장 공간 요구 감소, 자산 수동 복제 시간 단축 → 비용 절감

3.4Edge DNS

DNS의 한계를 극복하기 위한 Akamai의 Authoritative DNS 솔루션 (보안 상품으로 분류)

주요 기능

• DNSSEC 지원 — Authoritative DNS 변조 방지
• Anycast 기반 (VIP와 유사한 개념)
• 2차 DNS로 사용 시 1차(Master) DNS의 Zone Transfer로 zone 파일 동기화. Master에서 Agent IP를 허용해야 sync 가능 (해당 IP는 Akamai 측이 제공)
• 1차·2차 DNS 모두 사용 가능
• Akamai가 네임서버 6개 제공 — 전부 등록이 어려우면 낮은 번호부터 등록 권장 (적은 번호가 더 많은 대륙을 커버)
• 무차별 DNS 요청(DDoS)을 차단하지 않고 흡수
• 고가용성 100% SLA (24/7)
• Zone Apex Mapping — apex 도메인을 서브도메인 경유 없이 Edge IP로 직접 응답

경쟁사(Route 53) 대비 우위: 보안·방어적 도메인 관리, 이중화(Redundancy)

도입 이유 — 일반 DNS로는 root 도메인을 Akamai에 태울 수 없음 → Redirect 또는 Edge DNS 중 택일

3.5GTM (Global Traffic Management)

Akamai의 GSLB(Global Server Load Balancer) 서비스. Authoritative DNS를 활용해 여러 고객 DC 간 트래픽 Redirect·Load Balancing

특징 — DNS 대상, 클라우드 기반 / DR(재해복구), 지역 분산 용도 / 실시간 상태 기반으로 최적 DC 선택 / SLA 100%

등급

• Standard: 장애 복구, IP Intelligence(사용자 IP 기반 위치 판단), 가중치
• Premier: Standard 기능 + DC 성능 측정 기반 부하 분산

주요 동작

• 다른 DC로의 Failover — primary DC health check는 자주 하지만 rollback은 느린 편
• Weighted Load Balancing — DC별 정확한 비율 분산 (예: 30/30/40)
• 분산 비율이 100:0이 될 수도 있음 (캐시된 데이터는 TTL 동안 한쪽에서만 조회)
• 지역별 다른 설정 가능 (예: 한국은 Origin 직결, 해외는 Akamai DNS 경유)

로드밸런싱 기법: Random, Weighted Random, Mirror Failover, Performance, Load Feedback, Geographic Mapping, ASN/CIDR, IP Version Selection

트래픽 실시간 모니터링, 요약 리포트, Alerting 제공

3.6DOM (Domain Ownership Manager)

도메인 소유자가 실제로 해당 도메인 권한을 가지고 있는지 확인하는 절차. Validated 상태여야 Property 활성화 가능

Validate Scope

• HOST: www.example.com 단일 호스트만 인증
• DOMAIN: example.com 하위 전체 인증 (root 도메인만 입력하면 모든 서브도메인 커버)
• WILDCARD: *.example.com, test.*.example.com, *.test.example.com

3.7CPS (Certificate Provisioning System)

Client–Edge 구간 인증서를 관리하는 시스템

인증 방식

• EV (Extended Validation): 거의 사용되지 않음
• OV (Organization Validation): 기관 인증(전화) + 도메인 인증(메일/TXT). 1년 갱신, 자동 갱신 불가. SAN / Wildcard 모두 가능. DigiCert가 입력된 기관 정보를 확인해 인증
• DV (Domain Validation): TXT 레코드 수정으로 도메인 인증. 3개월 갱신, Akamai 설정으로 자동 갱신 가능. 무료, SAN만 가능

인증서 타입

• SAN: a.abc.com, b.abc.com … 최대 100개
• Wildcard: *.abc.com
• SAN + Wildcard
• Single: 도메인 하나 (a.abc.com)

3.8Reporting · Log

Reporting — 고객사의 Akamai 사용 현황 확인

• Traffic by Hostname — 조회 가능 기간 90일. CP Code 선택 시 데이터 출력
• 지표: HIT, Bytes(전송량), Offload(Edge vs Origin), Edge / Midgress / Origin
• URL 기준, GEO 기준 리포트 — Hostname/URL/GEO 세 리포트의 트래픽 수치는 서로 다르게 나올 수 있음 (집계 기준·요청 건수 차이)
• Scheduled Reports에서 예약 리포트 확인

Log - DataStream

• 특정 저장소로 실시간 로깅
• 로그 분석은 최대 48시간 이내 로그만 가능
• 고객이 로그를 요청하면 DataStream으로 직접 수신하도록 안내

4보안 기초 개념

4.1보안 장비 종류

• Firewall: inbound/outbound 특정 대역 차단
• DDoS 장비: 임계치 기반 차단 (예: 5초 100건 이상). L3/L4 구간에 임계치를 주로 설정
• WAF: L7(HTTP/HTTPS) 웹 트래픽만 검사. OWASP Top 10 기반 SQLi/XSS 등 탐지·차단
• IPS: SSH, SFTP 등 공격 차단
• IDS: IPS 트래픽을 미러링해 공격 탐지 (차단이 아닌 탐지)

4.2DDoS

여러 좀비 PC에서 동시에 한 대상을 공격

공격 유형

• Network Layer Attack (L3/L4): 대량 패킷으로 대역폭 마비
• Application Layer Attack (L7): 정상으로 보이는 HTTP 요청을 대량 반복해 처리 자원 소진. 봇 기반 자동화 요청 포함

4.3WAF

Web Application(HTTP/HTTPS) 대상 공격 탐지·차단. HTTP 요청의 실제 내용(URL, 파라미터, 헤더, 바디)을 검사해 악성 패턴 판별

주요 차단 대상

• SQL Injection: 요청 파라미터에 SQL 구문을 삽입해 DB 조작·탈취
• XSS: 악성 스크립트를 심어 방문자 브라우저에서 실행, 쿠키 탈취
  • Stored XSS: DB에 저장되어 모든 사용자에게 반복 노출 — 가장 위험
  • Reflected XSS: URL에 담겨 실행 시 한 번만 동작
  • DOM-based XSS: 브라우저의 JS가 URL 등을 처리할 때 취약점 발생
• Command Injection: 서버가 실행할 시스템 명령어를 요청에 삽입
• Path Traversal: 서버 내 임의 파일 접근 시도

차단 동작 방식

• 시그니처(패턴) 기반: 알려진 공격 패턴을 규칙으로 등록, 일치하면 차단
• 점수(Scoring) 기반: 하나의 요청이 여러 규칙을 위반하면 점수 누적. 단일 규칙만으로 확신하기 어려울 때 사용

4.4Bot

웹사이트·API에 스크립트가 사람 대신 요청을 보내는 것

분류

• Good Bot: 검색 엔진 크롤러(Googlebot), 모니터링 툴, 가격 비교 서비스
• Bad Bot: 콘텐츠 무단 복사 스크래퍼, Credential Stuffing, 매크로, API 무한 호출

문제점 — 리소스 낭비, 콘텐츠·데이터 탈취, 계정 탈취, 매크로를 통한 재고 선점

구분 방법 — 행위 패턴 분석 / 브라우저에서만 실행되는 JS를 삽입하고 통과 여부로 판단 / 비정상적이거나 조작된 헤더 사용 여부 / 짧은 시간에 동일 패턴 요청 반복

4.5Rate Limiting (일반 개념)

특정 클라이언트가 일정 시간 안에 보낼 수 있는 요청 수 제한

목적 — 비정상 트래픽 방어 / 정상 사용량 보호(클라이언트 코드 버그로 인한 API 무한 호출도 탐지) / 자원 공정 분배(독점 방지)

동작 방식

• 기준(Key) 설정: IP, 쿠키, API 키, 특정 헤더 중 무엇으로 카운트할지
• Threshold 설정: 몇 초/몇 분 동안 몇 건까지 허용할지
• 초과 시 Action: 차단 / 느린 응답 / CAPTCHA 등 추가 검증

4.6False Positive / False Negative

• False Positive: 정상인데 차단 → 정상 사용자가 서비스 이용 불가
• False Negative: 악성인데 통과 → 실제 공격이 뚫린 보안 사고

4.7Allowlist / Denylist

IP / Geo / User-Agent / API 키 기준으로 트래픽을 걸러내는 목록

• Denylist: 등록된 것만 차단
• Allowlist: 등록된 것만 허용

4.8CVE

알려진 취약점을 비영리기관 MITRE가 식별·정의·카탈로그화한 표준 참조자료

주요 특징

• 조직이나 소프트웨어 내부에 존재
• HTTP와의 연관성 유무는 취약점마다 다름
• 익스플로잇(공격 코드)이 존재할 수도, 없을 수도 있음
• 익스플로잇이 있어도 로컬에서만 악용 가능한 경우가 있음 (원격 공격 불가)

5Akamai Security

5.1Akamai 보안 처리 순서

Security는 CDN 위에서 수행 — 보안이 먼저 동작. 동일 서버 내에서 모든 Security 과정을 통과하면 같은 서버에서 CDN 로직 수행

AAP 통과 순서

1. IP/Geo Firewall
2. DoS Protection
3. (Custom Rules — DoS와 WAF 사이에서 동작)
4. WAF
5. (ASM 계약 시) Client Reputation
6. (ASM 계약 시) API Constraints
7. Bot Management

모두 통과 후 CDN 설정 확인 → Origin 도달

Bot 판별이 마지막인 이유: 가장 무겁고 정교한 연산이 필요하기 때문

우회 차단: 클라이언트가 Origin에 직접 접근하는 것을 막으려면 Origin 측에서 IP ACL 필요

5.2AAP (App & API Protector)

WAF / API 보안 / 봇 관리 / DDoS를 하나의 플랫폼으로 묶은 통합 보안 제품

적용 대상 상품: DSA, ION 전용 — DD, AMD는 정적 콘텐츠라 Origin 직접 처리 비중이 적음. DSA, ION은 동적 요청을 처리해야 하므로 Origin 보호가 필요

포함 요소: Site Shield, mPulse Lite, EdgeWorkers, Image Manager, API Acceleration

DDoS 방어

• Edge에서 Network Layer DDoS 즉시 차단, Application Layer DDoS 방어 전략 제공
• 속도 제한: 과도한 속도의 요청을 보내는 클라이언트 식별·제어
• URL 보호 및 지능형 Load 차단: 계산량이 많은 리소스를 원본 기반 속도 제한으로 보호
• Slow POST Protection: 매우 느린 요청 속도가 특징인 DDoS 방어

API 방어

• API Discovery: 알려진/알려지지 않은/변화하는 API를 웹 트래픽 전반에서 자동 검색
• 자동 API 검사: API 요청 내 악성 코드 자동 검사
• API 데이터 손실 방지: PII 처리 경고·시행으로 데이터 유출 및 규정 준수 위반 감지
• Positive API Security (API Constraints): 고객이 API 스키마를 정의하고 요청 본문·리소스 제약을 설정

Bot Protections — Known Bot 약 1,750개 디렉터리 접근 → 봇 트래픽 실시간 가시성 제공. 특정 봇 접근 허용 설정 가능

기타 — Client Reputation (ASM 결합 시 기본 제공) / 필터·임계값 기반 이메일 알림 및 모니터링

5.3AAP vs AAP with ASM

ASM(Advanced Security Management)은 AAP를 보완하는 상품. AAP 단독은 자동화된 보안 기능 위주, ASM 결합 시 세밀한 제어 가능

추가되는 핵심 기능

• Client Reputation (기본 포함)
• API Request Constraints
• Security Configuration을 여러 개 사용 가능
• WAF Manual 모드 사용 가능
• Custom Rule 무제한
• CVE Protections Lookup Tool

5.4ASE (Adaptive Security Engine)

Akamai WAF의 핵심 엔진, AAP에서 사용

구성 요소 (자동화 + 머신러닝 + 데이터 + 사람의 결합)

• Advanced Automation: 고객 환경·트래픽에 맞춰 스스로 튜닝하고 수정된 룰셋 자동 적용
• Machine Learning: 트래픽 분석으로 이상 징후 점수 정확도 향상, 오탐 감소
• 대규모 Intelligence DB: Akamai가 보유한 클라우드 보안 인텔리전스 데이터베이스
• 전담 Threat Hunter 조직: 24시간 공격 추적·분석

특징

• 실시간 분석: 모든 요청 특성을 Edge에서 실시간 분석 → 빠른 탐지
• 패턴 학습: 로컬·글로벌 데이터를 함께 활용해 고객별 맞춤 보호 조정
• 미래 위협 적응: 공격 기법이 진화해도 최신 보호 상태 유지. 제로터치 업데이트로 탐지 성능 개선

모드

• Automatic: Edge에 배포된 ASE 룰셋 자동 업데이트. 새 보안 정책 생성 시 기본값. 별도 노력 없이 최신 상태 유지
• Manual: 새 룰을 배포 전에 직접 평가하고 수동 활성화. 고객이 직접 업그레이드·테스트·설정해야 최신 상태 유지 (ASM 필요)

5.5Custom Rules · Rapid Rules

Custom Rules

• 표준 WAF/ASE 룰로 커버되지 않는 예외 상황에 사용
• DoS Protection과 WAF 사이에서 동작
• 조건: 메소드, 경로, 확장자, 헤더, 쿠키, 쿼리스트링, POST body 등
• 사용자가 직접 조정, 최후의 수단으로 신중히 사용 권장 (오탐 위험)

Rapid Rules

• 최근 발생한 고위험·고프로필 취약점(Zero-day)에 신속 대응
• 별도 설정 없이 업데이트되며 AI 기반 공격 탐지 지원

3단계 배포

• Initial Release: 효과가 확인되면 즉시 초기 버전 배포. 활성화 고객은 바로 신규 위협 탐지 시작
• Ongoing Release: 새 정보를 반영해 룰 튜닝·개선, 새 버전 릴리즈. 고객이 액션을 개별 제어하며 ASE와 별도로 운영
• Final Release: 개발 완료 시 정식으로 ASE에 편입

5.6Rate Limiting (Akamai 구현)

Edge에서 Client별 요청 속도를 제어해 Origin이 과도한 요청·DoS에 노출되는 것을 방지. Edge가 각 Client의 평균/버스트 요청 속도를 모니터링, Threshold 초과 시 Alert/Deny

동작 방식

• Rate Policy 정의 — 두 가지 임계값 + 클라이언트 식별자
  • Average: 2분 윈도우 기준 초당 요청 수
  • Burst: 1~5초 윈도우 기준 초당 요청 수
• 윈도우를 좁게 할수록 짧고 분산된 트래픽 스파이크 포착 가능 (공격자가 탐지를 피하려고 짧게 끊어 보내는 대량 트래픽)
• 좁게 설정하면 오탐 위험 증가 → 명확한 증거가 있을 때 사용

속도 계산 — Edge가 Qualification 기간 동안 클라이언트별 요청/응답 속도 계산. Edge들은 각각 자체 Rate Control Table을 유지하며 서로 공유하지 않음

Penalty Box 등록 — Average/Burst 중 하나라도 초과한 클라이언트를 기록, 기본 10분 유지 (10/30/60분 설정 가능). 후속 조치: Penalty Box 내 Client가 다시 요청하면 Rate Limiting Rule 발동

한계

• Credential Abuse → Bot Manager의 Behavioral Anomaly Detection 필요
• L3/L4 DDoS → Rate Limiting은 L7 대상 기법
• 정상 트래픽 급증 조절 → Bot Manager의 Configurable Actions로 대응

5.7URL Protection

Origin 보호에 초점, 미션 크리티컬 리소스 보호 및 트래픽 우선순위 설정. Origin으로의 RPS(Request Per Second)를 Global Rate Account 방식으로 집계해 최대 허용치 초과 요청 차단

Intelligent Load Shedding — 최대 RPS 도달 전, 악성 가능성이 높은 트래픽부터 우선 차단. 최대 RPS 초과 시 모든 요청 차단

Rule 설정 항목 — Host/Path 또는 API 매칭 기준 / 해당 Host/API(Origin)의 최대 RPS 한도 / Load Shedding 카테고리(RPS 한도에 근접할수록 우선 차단할 트래픽 유형)

실행 시점: Rate Limiting, IP/Geo Firewall, Reputation Controls, Bot Controls 등 다른 보안 기능이 모두 처리된 이후 마지막에 실행

5.8IP/Geo Firewall Protection

Network Layer Controls라고도 함. 특정 IP, CIDR 블록, 지리적 위치, ASN 기준으로 트래픽 차단·허용, 예외 처리 가능

• CIDR: x.x.x.x/24 형식의 IP 대역 표기
• ASN: 한 조직이 관리하는 IP 대역을 묶어 식별하는 번호

조건 지정 방법

• 보안 정책에 수동 직접 입력
• Network List: IP/CIDR, 지리적 위치로 식별
• Client List: IP/CIDR, Geo, ASN, File Hash, TLS Fingerprint로 식별 — Network List를 대체하는 권장 방식. 여러 속성 동시 설정 가능, 대량 붙여넣기/CSV 업로드로 관리, 태그·만료일·생성일 등으로 검색·필터링

Network List 활용 예: Tor 관련 Akamai 제공 리스트 사용 (해킹 용도 브라우저로 간주해 차단하는 것이 일반적)

5.9Site Shield

Origin을 인터넷상에서 은폐해 직접 공격받지 않도록 보호

동작

• Parent Edge 앞단에서 IP Map 생성 → 해당 대역으로만 Akamai와 Origin이 통신
• Origin은 이 IP 대역 외 모든 접근을 차단 (ACL로 80/443을 Site Shield Parent IP만 허용)
• 모든 트래픽이 Akamai를 경유

Site Shield Parent 서버 — Origin과 직접 통신 가능한 소수의 특정 Edge 서버 그룹. Origin 위치와 사용자 분포를 분석해 고객별 전용 맵(Site Shield Map) 생성

5.10Site Failover

Origin에 문제(다운, 응답 불가, 에러) 발생 시 5xx 대신 대체 콘텐츠를 제공하는 기능

문제 감지 — Edge가 Origin에 콘텐츠 요청 → 다운/타임아웃/특정 응답코드 반환 감지. Origin Health Detection이 실패한 IP 연결 시도를 모니터링해 판단

대체 동작

• 대체 사이트로 리다이렉트 (NetStorage, 다른 static origin, 점검 페이지, 백업 사이트)
• 캐시된(Stale) 콘텐츠 서빙

트리거 조건 설정: Origin 타임아웃, 특정 HTTP Status Code 등

5.11Malware Protection

Malware: IT 시스템을 손상·파괴하거나 해커에게 무단 접근 권한을 부여할 목적의 프로그램/파일

Akamai Malware Protection — 파일이 Origin에 도달하기 전 Edge 단에서 정적 분석으로 스캔해 악성 파일을 사전 차단하는 예방적 솔루션

차별점: 기존 ICAP/클라우드 스캐닝과 달리 Origin 설정이나 자체 인프라 구축 없이 Control Center에서 빠르게 도입 가능

5.12Bot Visibility & Mitigation (BVM)

AAP에 기본 포함되는 기본 봇 관리 기능

배경: 전 세계 트래픽 중 AI/Bot 비중이 매우 큼 → 어떤 봇이 들어오는지 파악하는 가시성(Visibility)이 우선

보호 유형 4가지

• Akamai Bot Categories: Akamai Security Research 팀이 식별·분류한 봇 (Verified Bot)
• Custom Bot Categories: 고객이 Request Header, ASN, Cookie 등으로 직접 정의한 봇
• Transparent Detections: 스스로 정체를 밝히지 않는 봇 탐지 — Known Bot 사칭 탐지, User-Agent 기반 탐지, 브라우저 사칭 탐지. Action 선택 외 별도 구성 단계 불필요
• Active Detections (Interstitial Challenge): JavaScript + Cookie 조합으로 실제 사람·실제 브라우저 여부 확인

Unknown Bot 처리 — 의도 불명이나 고객사는 알고 있을 수 있음. Custom Bot으로 분리 정의하는 작업 필요. Action을 monitor로 두면 로그만 수집하고 Property로 바로 통과

한계: Credential Abuse 등 정교한 봇 공격 방어는 BVM 범위 밖 → Bot Manager 필요

5.13Bot Manager Premier (BMP)

별도 구매 상품, AAP 선행 필요. Endpoint(JS) 기반 행위 검증 및 보호

계층 구조: BVM(기본) → BMP(정교한 봇 + Bot Score) → Account Protector(계정 탈취 특화)

핵심: 이진(사람/봇) 판정 대신 0~100 Bot Score로 대응 강도를 조절

설계 방식

• 로그인/체크아웃 같은 동적 페이지에는 행동 기반 탐지
• 정적 콘텐츠에는 기본 HTTP 평가
• 특정 경로만 탐지 가능 — Transactional Endpoint(사람이 행동하는 구간)를 대상으로 점수화

상품 페이지의 가격 정보를 긁어가는 사례가 많음. 링크로 다이렉트 접근하는 경우가 많아 봇 구별이 어려움

5.14Account Protector (APR)

로그인 페이지에서 계정 탈취(ATO), 신원 사기, 수동 자격증명 오용을 행동 기반으로 탐지. 계정 소유자의 행동 패턴, 전체 사용자 활동, 기기·IP·네트워크·평판 이상 징후를 프로파일링해 실시간 위험 평가

동작 원리 7단계

1. User Profiles: 이전 기기·위치·네트워크·활동 시간 등 개인 프로필 이상치로 사칭자 탐지
2. Population Profiles: 전체 사용자 집단 행동 프로필 기반, 첫 로그인부터 이상치 탐지
3. Sophisticated Bot Detections: 비지도·지도 학습 알고리즘으로 첫 상호작용에서도 적대적 봇 포착
4. Reputation Data: 전 Akamai 고객에 걸쳐 관찰된 과거 악성 활동 기반 소스 평판 평가
5. Real-Time Risk Scoring: 사용자 행동·기기·네트워크 평판 이상치를 종합해 세션 위험 점수화
6. 조직별 맞춤 튜닝: 각 조직의 트래픽·행동 패턴에 맞춰 머신러닝이 지속 튜닝
7. Enrichment: 인사이트를 사기 조사·SIEM 도구와 함께 활용

실무 예: 하나의 IP로 여러 device에 연결되면 봇으로 판별

5.15CPR (Content Protector)

스크래핑으로부터 콘텐츠를 보호하는 데 특화된 상품 (AAP 선행 필요)

Bot Manager와의 차별점 — 스크래퍼에 더 특화 / 과거 행위 이력 기반 위험도 평가 / 평판 점수(RS)로 관리 (특정 IP의 악성행위 연루 이력 등)

Scrapable Content: 스크래퍼에게 가치 있는 정보를 담은 HTML 또는 JSON

대상 고객: 지속적 스크래퍼 공격에 노출되어 가격/재고/상품정보, 평판, 매출을 보호해야 하는 조직

구현 시: 초기에는 스크랩 가능 영역을 Monitor 모드로 구현하고 Staging 테스트 필요

탐지 방식 2계층

• Stateless / Edge Detection Layer: Akamai Edge 서버에서 실행. HTTP header, TLS/TCP 협상 파라미터 등 연결 초기 이상 탐지. 미숙련 봇 탐지 + IP Intelligence 기반 cloud provider/corporate proxy 식별
• Stateful / Backend Detection Layer: Akamai Linode 상 별도 backend 컴포넌트로 실행. Edge 신호(server-side) + CPR 전용 JS(client-side, HTML에 injection)로 수집한 telemetry 기반 통계 모델. Device fingerprint, 행동 telemetry 이상, headless 브라우저 징후 탐지

오탐 분석 (WSA에서 트래픽 분석)

False Positive 주요 원인

• Misconfiguration — CPR 규칙 정의 시 AJAX URL referrer 누락, AVF 미활성화
• Non-standard client behavior — 프라이버시 중심 브라우저
• Detection Logic 자체 이슈

False Negative 특성

• 모든 보안 솔루션의 근본적 한계로 완전 해결 불가
• 주요 원인: headless browser + residential IP 조합. 봇넷 시그니처가 일반 브라우저와 거의 동일. 트래픽 분산도가 높아 IP/ASN 차단이 비효율적
• Custom Rule로 False Negative를 잡으려 하면 False Positive가 급증할 위험

5.16Client Reputation

Akamai에 유입되는 공격을 분석해 IP 주소별로 고객 맞춤형 평판 점수를 부여

• 공격 카테고리별 1~10점 척도(Reputation Score)
• 고객은 점수 기반 Reputation Rule로 Action 적용 (고위험 차단, 저위험 모니터링)
• 전제: 동일 IP라도 어떤 고객에게는 위협이고 다른 고객에게는 아닐 수 있음 — 내 서비스를 공격하지 않은 IP도 차단될 수 있음

핵심 로직: 커스텀 리스크 점수 → 정확도 향상 → 오탐 감소 → 정상 사용자 영향 감소

라이선스: ASM에 기본 포함, AAP 단독 고객은 애드온으로 별도 구매

활성화 구조 2단계 — Security Configuration의 Shared Resources에서 Reputation Profile 생성 → 정의된 Profile에 Response Action 적용

5.17API Constraints

Positive Security Model — 요청/응답 제약 조건을 직접 정의·강제해 과도하게 큰 요청으로부터 API 보호. 사전에 설정한 API 요청이 아닌 다른 요청이 오면 탐지·차단

사전 조건: ASM 모듈이 AAP와 함께 계약에 포함되어야 함

설정 4단계

1. Control Center에서 API Definition 생성(API 등록)
2. Request Body Constraint 정의
3. Resource 및 Resource Constraint 정의
4. Security Policy 내 API Request Constraints Protection 구성

5.18AAP Hybrid

온프레미스·멀티클라우드·멀티CDN 환경까지 확장한 솔루션. 기존 AAP와 결합해 Akamai WAF 보호 범위를 CDN 바깥(off-CDN)까지 확장

트래픽 유형

• Akamai On-CDN: Akamai Edge를 경유하는 트래픽
• Off-CDN: Edge를 거치지 않는 트래픽
• Off-Internet Traffic: 사설 트래픽

5.19Security Configuration 관리

• CDN Property와 동일한 구조로 관리
• Staging / Production 환경 동일하게 존재, 버전 관리 가능
• AAP 단독은 Security Config를 하나만 사용 가능 — 보안 적용 대상 모든 도메인이 하나의 Security Config에 포함. Config 내 Policy에서 보안 룰 적용, 개수 제한 존재
• AAP with ASM은 Security Config를 여러 개 사용 가능

5.20Action 유형 구분

• Alert: 단순 탐지. 탐지 순서는 Top-down 방식. 부합하는 룰이 3개면 3개 모두 한 번에 Alert 기록 → 계속 탐지한다는 의미
• Monitor: 부합하는 항목을 찾으면 거기서 더 이상 탐지하지 않음 (이미 정의된 상태이므로 추가 탐지 불필요)
• Deny: 차단
• Abort (Slow POST 전용): Client에 HTTP 응답을 보내지 않고 Origin으로도 전달하지 않은 채 연결 자체를 종료

6모니터링 · 리포팅 도구

6.1Security Center

매크로 관점의 이상 징후·분석 대상 식별

제공 정보

• Traffic Trend, Traffic Report
• Attack Traffic — 순수 공격 트래픽만은 아니며 측정용 트래픽이 포함될 수 있어 비율이 높게 보일 수 있음
• Bot 유형별 카테고리
• 활성화한 보호 기능들이 실제로 어떻게 처리되고 있는지 지속 모니터링·평가

6.2WSA (Web Security Analytics)

• 위젯으로 커스텀해 원하는 정보를 구성
• Request 단위까지 확인 가능한 심층 분석 도구
• Samples View로 개별 요청 상세 확인

6.3SIEM Integration · Log Delivery

SIEM (Security Information and Event Management) — 여러 위치의 로그를 한 곳에 모아 종단(end-to-end) 관점에서 분석

Log Delivery Service — Akamai 인프라가 전 세계 Edge에서 지속적으로 로그 수집. 해당 고객의 로그만 분리해 복사본 생성, 정해진 스케줄에 따라 전달

7트러블슈팅

7.1공통 4단계 프레임워크

Stage 1: 정보 수집 (Analyze and Collect Information)

• 에러 메시지, 최근 변경 사항, 시스템 로그 등 핵심 정보 확보 — 목적: 문제의 명확한 그림을 그려 원인·패턴 파악을 쉽게 함
• Origin 자체 문제 여부 확인 — Origin에 직접 curl 요청

  curl -v https://<origin-IP> -H "Host: www.mywebapp.net"

  Origin 측 방화벽이 요청을 허용하는지 확인
• 애플리케이션이 Akamai를 정상적으로 가리키는지 확인 (AAP 한정) — dig <hostname>으로 Akamai CNAME으로 resolve되는지 확인. Akamai를 가리키지 않으면 고객 DNS 설정 문제 가능성
• Kubernetes Cluster 정상 여부 (AAP Hybrid 한정) — Cluster 자체(API Server, Node, Networking)의 상태를 먼저 확인

Stage 2: 서비스 구성 검토 — 설정된 Service Option 점검 / 공식 문서 Best Practice 준수 여부 확인

Stage 3: 기본 트러블슈팅 조치 — 설정 오류 수정, 서비스 재시작, 알려진 Fix 적용

Stage 4: 벤더 지원팀 에스컬레이션 — 조건: 기본 트러블슈팅으로 해결되지 않을 때. 에스컬레이션 시 필수: 수집한 모든 정보 + 이미 시도한 조치 요약

7.2인증서 관련

고객이 "Client에서 접속 시 Origin 인증서가 보이지 않는다"고 문의하는 경우 — CDN 사용을 중지하고 hosts 파일에 Origin 서버를 등록해 직접 접속해보는 방식으로 확인

7.3Site Shield

핵심 점검 3가지

• Site Shield Map이 해당 Hostname/Application에 맞게 구성되어 있는가
• Site Shield가 해당 애플리케이션을 서빙하는 Property 내에 추가·구성되어 있는가
• Origin을 보호하는 WAF/방화벽에 Site Shield IP만 화이트리스트되어 있는가

1단계: Map 설정 확인 — 경로: Control Center > Web & Data Security > Security Configurations > Site Shield

• Protected Hostname: 정확한 Hostname으로 생성되었는지
• Current Addresses: 여기 나열된 IP가 고객 방화벽 화이트리스트와 일치하는지
• Notification Status: Map이 Active 상태인지

2단계: Property 내 구성 확인 — 경로: Control Center > CDN > Properties

• Property 검색 → Production Active 최신 버전 오픈 → "Site Shield" 섹션 검색
• Map이 여러 개면 드롭다운에서 올바른 Map이 선택되어 있는지 확인
• Map 미할당 시 "There is currently no Site Shield Map assigned to this property" 경고 표시

3단계: Origin 방화벽 화이트리스트 확인 — 고객에게 Site Shield IP만 허용되어 있는지 재확인 요청

7.4Site Failover

• Step 1: 기능이 추가되어 있는가 — Property의 Behavior 목록에 Site Failover 포함 여부
• Step 2: 기능이 활성화되어 있는가 — Behavior가 Enabled 상태인지 / Server Response Status Codes가 올바르게 설정되어 있는지 (예: 503, 504에서만 동작)
• Step 3: 원하는 Action이 선택되어 있는가 — 다른 위치/Hostname으로 리다이렉트 / 캐시된(Stale) 콘텐츠 서빙. 고객 요구사항 및 테스트 시나리오와 일치하는지 확인
• Step 4: 값이 올바른가 (Origin Health 연계) — Origin Health Behavior의 Retry Count, Maximum Reconnects 값 점검. 값이 너무 높으면 리다이렉션이 지연되어 UX에 부정적 영향

7.5IP/Geo Firewall

전제: Client List(s)와 IP/Geo Firewall Protection 두 컴포넌트가 모두 설정되어야 동작

Client List 점검 — 경로: Security Configuration > Shared Resources > Client List

• Type 확인: IP/CIDR, GEO, ASN 3종 중 목적에 맞는 Type인지
• Record 정확성: 필요한 IP/CIDR 범위, GEO 위치, ASN 번호가 빠짐없이 포함되었는지
• 상태 확인: Production 환경에서 Active 상태인지

IP/Geo Protection 점검

• 올바른 Client List가 선택되어 있는지
• XFF Header 확인 — AAP는 차단 판단 시 Connection IP Address와 X-Forwarded-For 두 값을 검사. 차단 대상 IP/지역에서 요청을 보내본 뒤, 브라우저 개발자 도구에서 XFF Header 포함 여부 확인
• Security Configuration이 Production에서 Active 상태인지

7.6DDoS Protection

구성 요소 4가지

• Layer 3 / Layer 4 Protections — 모든 Security Configuration에 기본 활성화
• Rate Limiting Policy
• URL Protection
• Slow POST Protection

Rate Limiting 점검 — 구조: Shared Resources에서 Rate Policy 정의(Average/Burst Threshold) + Action 할당(Alert/Deny)

• Security Configuration > Shared Resources에서 Rate Policy 설정 확인
• Rate Policy에 Deny Action이 할당되어 있는지 확인 (Deny가 아니면 Alert만 발생)

URL Protection 점검

• Shared Services에서 구성한 Rule은 Security Configuration의 DoS Protections 목록에 표시됨
• 구성된 Rule이 Deny Action으로 설정되어 있는지 확인

Slow POST Protection 점검

• Configuration 내에서 Enabled 상태인지
• Continuous Rate, During Any Threshold 값이 의도대로 설정되어 있는지
• 원하는 Action(Alert / Abort)이 선택되어 있는지

7.7WAF

구성 요소

• WAF Protections: Akamai가 업계 리서치·Best Practice 기반으로 만든 보안 룰 그룹 (SQL Injection, Remote File Inclusion 등)
• Rapid Rules: 최신·고위험 취약점 신속 대응 룰 세트

점검 항목

• 활성화 여부: Security Configuration에서 WAF Protection이 Enabled인지
• 모드 확인: Automatic / Manual 중 고객이 원하는 모드가 정확히 선택되어 있는지
• Exception 확인 (차단되어야 할 요청이 차단되지 않는 경우) — Exception이 설정되어 있는지, 문제의 요청이 그 범위에 해당하는지
• Manual 모드 최신화 여부 — Manual은 룰이 자동 업데이트되지 않아 최신 위협 대응이 안 될 수 있음
• Attack Group Action 확인 — Attack Group 단위 또는 개별 Rule 단위로 Action 설정 가능. 특정 Attack Group(예: SQL Injection)이 차단되지 않으면 Deny Action 적용 여부 확인

7.8API Constraints

API Definition 확인 — 경로: Control Center > CDN 그룹 > API Definitions

• Production 배포 버전을 선택해 검토
• 올바른 Hostname과 API Endpoint가 구성되어 있는지
• Constraint 강제 여부: 고객이 강제(enforce)를 원하면 해당 API Definition에서 활성화되어 있는지
• Unidentified Resources 처리: "Include Unidentified Resources" 옵션 활성화 여부
• Request Body Constraint가 고객 요구사항과 일치하는지

Resource 정의 세부

• Path: Hostname 및 Base Path 기준 상대 경로로 올바른지
• Method: 기대하는 정확한 HTTP Method가 선택되어 있는지

Security Configuration 최종 확인 — API Request Constraints 기능이 On인지, 올바른 API가 지정되었는지, 원하는 Action이 선택되었는지

7.9Bot Visibility & Mitigation

Akamai Bot Categories — 증상: 정상 클라이언트나 Good Bot이 애플리케이션에 접근하지 못함. 확인: 해당 클라이언트가 Bot으로 잘못 분류되지 않았는지, Deny Action이 아닌지

Custom Bot Definition — 증상: 허용되어야 할 트래픽이 차단되거나, 차단되어야 할 트래픽이 허용됨. 경로: Security Configuration > Shared Resources > Custom Bot Categories. Bot Definition 자체의 정확성 분석 → 정의가 맞다면 Action 할당 여부 확인

Transparent Detections — Action 선택 외 별도 구성 단계 없음 → Category별 Action 정의 여부만 확인

Active Detection (Interstitial Challenge) — Security Configuration에서 Active Detection이 Enabled인지. Hostname/Path 매치 조건, Protection Mode, Cookie 관련 Action 확인

7.10Client Reputation

Shared Resources에서 고객이 정의한 Reputation Profile 검토. 해당 Profile에 적절한 Action이 할당되어 있는지 확인

7.11AkaTec 에스컬레이션

필수 제공 정보

• 고객 Account Name 및 ID
• AAP 또는 AAPH Configuration Name
• 이슈 상세 설명
• 이슈 발생 일시
• 재현 절차 (가능한 경우)
• 증빙 자료 (리포트 스크린샷, 터미널 캡처 등)

Non-Urgent - Chat (1차 권장) — 용도: 온라인 세션 중 즉시 해결 가능한 간단한 문제 (예: Control Center 비밀번호 초기화). 절차: control.akamai.com 접속 → Support 타일 → Support Chat → Community Page에서 카테고리 선택 → Launch Chat

Non-Urgent - Ticket (2차) — 용도: 복잡한 이슈, 스크린샷/로그덤프/설정 데이터 첨부가 필요한 경우. 절차: control.akamai.com → Support 타일 → Open the support case → New Case → 카테고리/제품/문제 유형 선택, Subject·Description 작성 → Severity 설정 및 첨부 → Create

Urgent - Phone — 연락처: (877) 4-AKATEC (미국/캐나다 무료) 또는 +1-617-444-4699. ACC 상단 바 책 아이콘 > Support Contacts에서 지역별 연락처 확인. 전화 전에 최대한 많은 정보를 준비해야 신속 대응 가능

8부록 - 원문 정정 목록