API Security & Gateways

1. Overview

API 보안 및 게이트웨이(API Security & Gateways, ASG)는 보이지 않는 수천 개의 수리적 구멍(Endpoints)을 통해 데이터가 노출되는 '연결 보안 부채'를 청산하고, 모든 API 요청이 정해진 물리 정책에 따라서만 하드웨어에 도달하도록 강제하는 '트래픽 통제 공학'입니다.

학습자는 모바일 앱이나 서드파티 하드웨어의 권한을 대리 수행하는 OAuth2/OIDC의 수리적 수순과, 무수히 쏟아지는 요청 속에서 악질적인 봇을 물리적으로 걸러내는 API 게이트웨이의 역할을 배웁니다. 특히, API 고유의 취약점인 **BOLA (Broken Object Level Authorization)**의 수치적 침투 경로와 해법을 익힙니다. 이를 통해 현대의 분산 시스템 환경에서 데이터가 흐르는 모든 물리적 통로를 완벽히 장악하는 하이엔드 인터페이스 거버넌스 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• API Authentication: OAuth2, OpenID Connect(OIDC), API Key의 수리적 검증 메커니즘
• Token Security: JWT(JSON Web Token)의 조작 방지 및 물리적 서명 검증 수순
• API Gateway Functions: 인증 통합, Rate Limiting, 프로토콜 변환의 물리적 배치
• API Specific Attacks: BOLA, Mass Assignment, 데이터 과다 노출의 수리적 탐지
• Throttling & Quota: 하드웨어 자원 보호를 위한 API 호출량의 수치적 제산

Out-of-Scope

• API를 만드는 서버 측의 기본 시큐어 코딩 상세 (10-03-02 SCI 영역에서 분담)
• 네트워크 전송 계층의 암호화(SSL/TLS) 자체 물리 기술 (10-01-04 DRI 영역에서 분담)

Boundaries

• ASG vs. SCI: SCI(10-03-02)가 '개별 코드 한 줄'의 안전에 집중한다면, ASG는 '서비스 간, 클라이언트-서버 간'이라는 외부 통로의 논리적 연결성과 그 통로를 지키는 하드웨어 관문에 집중하여 구분합니다.

3. Counterexample

• 단순히 "토큰 기반 인증 사용"이라 설명하는 것은 ASG 학습이 아닙니다. 왜 로그아웃된 JWT가 서버 하드웨어 메모리상의 블랙리스트 없이 여전히 수리적으로 유효하여 보안 구멍을 만드는지 증명할 수 있어야 하며, API 게이트웨이가 모든 트래픽을 검수하면서도 물리적인 응답 지연($Latency$)을 수치적으로 증가시키지 않기 위해 어떤 비동기 처리 구조를 갖춰야 하는지 논증하지 못한다면 API 보안의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Web Protocols & API Paradigms (Basic): 08-03-XX의 REST, HTTP Methods, Header 구조 이해가 필수입니다.
• Identity Protocols (Recommended): 10-04-03의 위임 인증 및 토큰 발급 수순 이해가 권장됩니다.

5. Learning Map

1. The Digital Tollbooth: 모든 API 호출이 반드시 거쳐 가야 하는 물리 검문소(Gateway)를 세웁니다.
2. Validated Passports: 호출자가 "누구이며 무엇을 할 수 있는지" 수리적으로 증명하는 토큰 시스템을 구축합니다.
3. Data Spill Prevention: 필요한 것보다 더 많은 정보를 하드웨어가 뱉지 않도록 수치적 필터를 입힙니다.
4. Adaptive Flow Control: API 호출 패턴을 분석하여, 유효한 기기의 요청만 물리적으로 허용하는 하이엔드 제어권을 확보합니다.

6. Learning Topics

Basic

Core: API 인증과 토큰의 수리적 구조 (Token Physics)

• Why to Learn: 아이디/패스워드를 직접 보내지 않고도, 수만 번의 API 호출을 물리적으로 안전하게 수행하기 위해서입니다.
• What to Learn:
  • API Keys vs Bearer Tokens: 단순 식별과 위임 권한의 수리적 차이
  • JWT Structure: Header, Payload, Signature로 이루어진 물리적 데이터 뭉치
  • Token Validation: 서버 하드웨어가 DB 조회 없이 토큰의 진위를 수리 판정하는 법
• How to Learn:
  • jwt.io에서 토큰을 분해해보고, 페이로드 수치를 1바이트만 바꿨을 때 물리적 서명 검증이 왜 실패하는지 확인 실습
  • API Key가 URL 파라미터로 노출될 때 발생하는 물리적 스니핑 위험성 연구
• Implement: JWT를 생성하고 공개키로 서명을 검증하는 기초 SecureTokenEngine

Recommended

Core: API 게이트웨이의 물리적 배령 (Gateway Mechanics)

• Why to Learn: 각 서버마다 보안 로직을 짤 필요 없이, 입구에서 수만 대의 마이크로서비스 보안을 통합 관리하기 위함입니다.
• What to Learn:
  • Authentication Offloading: 개별 서버 하드웨어의 인증 부담을 게이트웨이로 물리적 이전
  • Rate Limiting & Throttling: 특정 앱이 API를 과다 호출하여 전체 시스템을 마비시키는 물리적 현상 방어
  • Request Transformation: 게이트웨이 통과 시 헤더를 수리적으로 수정하여 보안 정보를 주입하는 법
• How to Learn:
  • Kong이나 AWS API Gateway를 설정하고, 초당 호출 횟수($RPS$) 제한을 걸어 429 에러가 물리적으로 뜨는 시점 측정 실습
  • 게이트웨이 로그를 분석하여, 공격자가 시도하는 무차별 대입($Brute-force$)의 수리적 패턴 식별 훈련
• Implement: 유효한 API Key가 없으면 하부 서버로 요청을 물리 전달하지 않는 ProxyGuard

Practical

Core: API 고유 취약점 대응 (Advanced API Defense)

• Why to Learn: 겉보기엔 정상적인 호출인데 사실은 남의 데이터를 훔치는 고차원적인 논리 공격을 막기 위해서입니다.
• What to Learn:
  • BOLA (Broken Object Level Authorization): /v1/users/123 주소를 124로 바꿔서 남의 정보를 보는 수리적 허점
  • Insecure Direct Object References (IDOR): 하드웨어 내부 식별자가 외부에 수치 그대로 노출되는 물리 위협
  • Mass Assignment: 요청에 쓸데없는 필드를 섞어 넣어 하드웨어의 관리자 권한을 수리적으로 얻는 법
• How to Learn:
  • 자신의 실제 API에서 다른 사용자의 ID로 요청을 보내보고, 서버가 "요청자의 토큰"과 "데이터의 소유주"를 수리 대조하는 로직 분석 실습
  • API 응답값에서 불필요한 하드웨어 정보(Internal IP 등)가 물리적으로 실려 나가는지 인스펙션
• Implement: 객체 접근 시 소유권을 반드시 수치 대조하는 전역 OwnershipInterceptor

Advanced

Core: API 거버넌스와 AI 기반 탐지 (Scalable API Ops)

• Why to Learn: 수천 개의 API가 생겨나고 사라지는 거대 하드웨어 생태계에서 '잊혀진 보안 구멍'이 생기지 않게 하기 위함입니다.
• What to Learn:
  • API Discovery: 새로 생겨난 비공식 API(Shadow API)를 물리적으로 자동 찾아내기
  • Behavioral Anomaly Detection: 정상적인 앱 사용 패턴을 수치화하고, 이를 벗어난 토큰 탈취 시도를 물리 식별
  • mTLS for Service Mesh: 서버와 서버 사이의 통신(East-West)조차 상호 인증서로 물리 보호하는 기제
• How to Learn:
  • 서비스 메시(Istio 등) 환경에서 두 서버 간에 암호화된 mTLS 채널이 수리적으로 어떻게 수립되는지 패킷 캡처 실습
  • 수조 건의 API 호출 시계열 데이터에서 '급작스러운 대량 다운로드'를 수치적으로 잡아내는 경보 시스템 연구
• Implement: 비정상적인 호출 빈도 발생 시 해당 유저의 권한을 물리적으로 즉각 일시 정지시키는 AutoSentry

7. Terminology

8. References

Primary

• [P3] CyBOK - Software Security Knowledge Area (API & Service Security) — Definitive security context.
• [P5] SFIA v9 - Software Engineering / Methods and tools (Information security) — Management requirements.

Secondary

• [Advanced API Security] Prabath Siriwardena — The deep dive into OAuth and JWT.
• [RFC 6749: The OAuth 2.0 Authorization Framework] — The technical source of truth.

Industry

• [OWASP API Security Top 10] — The most important reference for ASG.
• [Google Apigee: API Security Best Practices] — Reference architecture.

9. Final Checklist

Primary

• 'API 게이트웨이'가 마이크로서비스 아키텍처에서 '보안 결합도'를 수리적으로 어떻게 낮추는지 설명 가능한가? (P3)
• 'JWT'의 '무상태성(Statelessness)'이 하드웨어 스케일링과 보안 사이에서 어떤 수리적 트레이드오프를 갖는지 기술할 수 있는 가? (P3)

Secondary

• 'OAuth 2.0'의 'Authorization Code Flow'가 'Implicit Flow'보다 물리적으로 왜 더 안전하게 설계되었는지 수치적으로 소통 가능한가?
• Mass Assignment 취약점이 하드웨어의 프레임워크 자동 바인딩 로직에서 어떻게 수리적으로 촉발되는지 논증할 수 있는 가?

Industry

• 실무 서비스 환경에서 API 호출의 '속도 제한($Rate Limit$)' 수치를 사용자의 물리적 가치(구독 등)에 따라 동적으로 제안할 수 있는 가? (SFIA)
• Shadow API의 위험성을 방지하기 위해 'Swagger/OpenAPI' 정의서와 실제 하드웨어 엔드포인트를 수치 대조하는 수순을 분석할 수 있는 가?