API 보안: API 보호 모범 사례
오늘날의 API 중심 소프트웨어 환경에서는 API 보호를 사후에 추가하는 것이 아니라 개발 프로세스에 API 보호 기능을 구축하는 API 보안 전략을 수립하는 것이 중요합니다.
오늘날 API는 많은 비즈니스 모델의 기본 요소입니다(때로는 비즈니스 모델 그 자체이기도 합니다). API는 최신 애플리케이션의 기본 프레임워크를 형성하며 개발자가 앱에 소프트웨어 구성요소를 삽입하여 기능 확장하고 사용자 경험을 향상시킬 수 있게 해줍니다.
API는 크게 네 가지 유형으로 분류할 수 있습니다:
- Public – 누구나 사용할 수 있습니다(예: Google 지도).
- Private – 내부 팀 또는 애플리케이션 클러스터 내에서만 사용 가능
- Partner – third-party 공급업체와 통합된(예: Netflix를 스마트 TV에 설치할 수 있는 API)
- Third-Party -제3자에 의해 노출되고 해당 서버에 위치
API 유형에 대해 자세히 알아보려면 API Connectivity에 대해 읽어보세요.
API는 빠른 현대화의 원동력이지만, 개방적인 특성으로 인해 민감한 데이터가 노출될 수도 있습니다. F5의 보고서에 따르면, API 사고의 약 3분의 2가 API가 완전히 노출되어(접속 제한 없이) 발생했습니다.
목차
1. API 보안이 중요한 이유는 무엇입니까?
1-1. API Sprawl
1-2. OWASP API Security Top 10
2. 어떻게 API를 보호하나요?
2-1. API 보안을 구현할 위치
2-2. API-First 및 API Governance
2-3. API Discovery
3. API 프로토콜: SOAP, REST, GraphQL을 위한 API 보안
3-1. SOAP APIs
3-2. REST APIs
3-3. GraphQL APIs
3-4. 일반적인 위협: SOAP과 REST, GraphQL API 비교
3-5. 모범 사례: SOAP와 REST, GraphQL API 비교
4. 다양한 배포를 위한 API 보안
5. API 보안 계층
6. API 보안 모범 사례
6-1. API Gateway 및 웹 애플리케이션 방화벽
6-2. 암호화
6-3. 인증 및 권한 부여를 위한 OAuth 및 OpenID 연결
6-4. 모니터링, 감사 및 로깅
6-5. API 보안을 위한 제로 트러스트
7. NGINX의 지원 방법
1. API 보안 이 중요한 이유는 무엇입니까?
수많은 앱이 API를 통해 자산을 즉시 제공하기 때문에 신속한 보호가 필수적입니다. 악의적인 공격자들은 API 설계의 다양한 취약점을 이용해 무제한 액세스를 시도하는 경우가 많습니다. HTTP 웹 요청과 마찬가지로 API 호출에는 공격에 취약한 URI, 메서드, 헤더 및 기타 매개변수가 포함됩니다.
1-1. API Sprawl
잠재적인 공격 표면을 증가시킨 최신 API 생태계의 핵심 요소는 API 엔드포인트의 확산입니다. 이를 API sprawl이라고 하며, API 에코시스템의 보안에 심각한 위협이 될 수 있습니다. 강력하고 안전한 API 인프라를 구축하기 위한 첫 번째 단계는 API sprawl을 관리하는 것입니다.
API sprawl은 디지털 트랜스포메이션 과정에서 발생하는 두 가지 문제에서 비롯됩니다:
- API 수의 기하급수적인 증가
- 여러 아키텍처와 팀에 걸친 API의 물리적 분산
최신 마이크로서비스 아키텍처의 채택이 증가함에 따라 이러한 아키텍처는 인터페이스(north-south 트래픽)와 마이크로서비스 간(east-west 트래픽) 통신에 많은 수의 API를 사용하기 때문에 API sprawl이 악화될 수 있습니다.
API sprawl에 대응하기 위한 전술은 다음과 같습니다.
- API governance 전략 구현
- API discovery를 위한 신뢰할 수 있는 단일 소스 만들기
- 적절한 버전 관리 및 문서화 보장
- API 트래픽에 대한 메트릭과 가시성 제공
- 대규모로 API 보안 적용
이러한 전략과 이를 구현하는 방법에 대해 자세히 알아보려면 API sprawl을 방지하는 5가지 방법을 읽어보세요.
API 엔드포인트의 확산에 따른 영향과 통계에 대해 자세히 알아보려면 F5의 보고서, 지속적인 API sprawl을 읽어보십시오: API 중심 경제의 도전과 기회.
1-2. OWASP API Security Top 10
Open Web Application Security Project(OWASP)는 OWASP API Security Top 10 프로젝트에서 가장 일반적인 API 취약점을 강조합니다.
- API1. Broken Object Level Authorization – 객체(Object) 식별자를 처리하는 엔드포인트가 노출되어 광범위한 공격 표면이 생성됩니다.
- API2. Broken User Authentication – 인증 메커니즘의 잘못된 구현으로 인해 공격자가 인증 토큰을 손상시키거나 합법적인 사용자의 신원을 도용할 수 있습니다.
- API3. Excessive Data Exposure – 개발자는 종종 모든 객체 속성을 노출하여 클라이언트가 사용자에게 도달하기 전에 데이터 필터링을 실행해야 하는 부담을 줍니다.
- API4. Lack of Resource & Rate Limiting – API는 클라이언트/사용자가 요청할 수 있는 리소스 수(또는 크기)에 제한을 두지 않는 경우가 많으며, 이로 인해 API 서버 성능 저하, 서비스 거부(DoS), 인증 결함이 발생할 수 있습니다.
- API5. Broken Function-Level Authorization – 계층, 그룹, 역할이 다양한 액세스 제어 정책은 권한 부여 문제를 야기하며, 공격자는 이를 악용하여 다른 사용자의 리소스 및/또는 관리 기능을 획득할 수 있습니다.
- API6. Mass Assignment – 공격자는 허용 목록에 기반한 잘못된 속성 필터링으로 인해 개체 속성을 수정할 수 있습니다.
- API7. Security Misconfiguration – 불완전한 구성, 개방형 클라우드 스토리지, 잘못 구성된 HTTP 헤더 등의 구성 실수로 인해 보안이 악용될 수 있습니다.
- API8. Injection – Injection 결함(예: SQL. NoSQL, Command Injection)은 신뢰할 수 없는 데이터가 명령이나 쿼리를 통해 인터프리터로 전송될 때 발생하며, 공격자는 이를 악용하여 의도치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 액세스할 수 있습니다.
- API9. Improper Assets Management – API는 수많은 엔드포인트를 노출하기 때문에 악의적인 공격자가 버그를 악용하는 것을 방지하기 위해 적절한 최신 문서가 필요합니다.
- API10. Insufficient Logging & Monitoring – 공격자는 로깅, 모니터링, 사고 대응과의 통합이 부적절할 때 공격 시스템을 더욱 발전시키고 지속성을 유지하여 데이터를 추출하거나 파괴할 수 있습니다.
2. 어떻게 API를 보호하나요?
API 보안의 필요성에 대한 인식이 널리 퍼져있음에도 불구하고, headline-grabbing 침해 사고는 여전히 발생하고 있습니다. Gartner는 보고서 “API 보안: API를 보호하기 위해 알아야 할 사항“이라는 보고서에서 애플리케이션팀 리더가 API를 보호하기 위해 효과적인 보안 전략을 설계해야 한다고 강조합니다.
보안은 설계부터 개발, 배포에 이르기까지 API 수명주기의 모든 단계에 구축되어야 합니다. 하향식 보안 접근 방식에서 볼 수 있는 discovery tool은 필수 구성 요소이지만, 적절한 API 보안은 API를 구축하고 배포하는 팀에서 시작한다고 생각합니다(아래의 API-First 및 API Governance 참조). 앱 및 API 보안에 대한 이러한 접근 방식은 software development lifecycle(SDLC) 초기에 보안 제어를 적용하고 CI/CD 파이프라인에서 자동화할 수 있는 “shift left”로 알려져 있습니다.
Shift left 접근 방식은 protect right하는 것으로, 네트워크 엣지에서의 위협에 대응하기 위해 API discovery 및 Web Application Firewall(WAF) 사용과 같은 방법을 우선시합니다. Protect right도 중요한 방어선이지만, Shift left 하는 것이 설계상 안전한 애플리케이션을 구축하는 데 중요하다고 생각합니다. CI/CD 파이프라인에 방어 기능을 구축하고 공격을 조기에 포착하지 않으면 공격이 발생했을 때 신속하게 대응할 수밖에 없으며, 때로는 역방향으로 대응하게 됩니다.
2-1. API 보안 을 구현할 위치
API 보안은 여러 팀과 시스템과 중복됩니다. 이 표에는 API 보안을 포함해야 하는 몇 가지 핵심 사항이 요약되어 있습니다. 여러 계층을 포괄함으로써 강력한 보호 수준을 달성할 수 있습니다. 이러한 방법과 기술은 API Gateway 또는 일련의 아키텍처 검사 지점에서 구현되는 경우가 많습니다.
| Access Control | Network Security | Runtime Protection | |
| Description | API 엔드포인트에서 인증 및 권한 부여 관리하기 | 안전한 네트워크 통신 제공, 네트워크 수준에서 원치 않는 트래픽 차단 | 봇(Bot) 완화 기술을 사용하여 일반적인 소프트웨어 취약성을 완화하고 API 남용을 방지하세요. |
| Technologies | OAuth 2.0, OpenID Connect(OIDC), JSON 웹 토큰(JWT), 무작위 API 키 | mTLS, DDoS 완화, 전송률 제한, 암호화 | 웹 애플리케이션 방화벽, JSON 스키마 유효성 검사, 공격 시그니처, 이상 징후 탐지 |
2-2. API-First 및 API Governance
점점 더 많은 팀이 API 우선 개발 모델을 구현하는 것을 볼 수 있습니다. API 우선이란 애플리케이션 설계를 고유하고 기본적인 제품으로 간주하는 API에서 시작한다는 의미입니다.
API 우선 모델의 주요 이점 중 하나는 API 거버넌스를 간소화하여 복잡한 시스템에 대한 제어와 가시성을 제공한다는 것입니다. 이를 통해 전체 수명 주기 및 잠재적인 발전 과정에서 API의 보안을 유지할 수 있습니다.
참고: API 거버넌스에는 여러 가지 접근 방식이 있지만, 개발자에게 권한을 부여하고 플랫폼 운영팀에 API의 안정성과 보안을 유지하는 데 필요한 제어 권한을 부여하는 적응형 거버넌스를 권장합니다.
2-3. API Discovery
처음부터 적절한 거버넌스를 구축하면 API를 사용하는 개발자와 이를 보호해야 하는 보안팀 모두 API를 쉽게 discovery 할 수 있습니다. 하지만 대부분의 조직은 효율적이고 확장 가능한 API 거버넌스를 구축한 상태에서 시작하지 않습니다. 대신, 기존 API는 물론 새로운 API 전반에 걸쳐 API 거버넌스 및 보안을 구현해야 합니다.
API가 광범위하게 채택되면서 한 가지 심각한 문제가 발생했는데, 바로 API가 작성자(API 개발자) 외에는 아무도 모르게 프로덕션 환경에 도입되는 경향이 있다는 점입니다. 때때로 이는 설계 및 배포 프로세스에서 간과되는 경우가 있습니다. 이러한 PAI를 흔히 “shadow APIs”라고 합니다.
다른 시나리오에서는 개발자가 다른 역할이나 프로젝트로 이동하여 결국 API의 존재를 아는 사람이 아무도 없게 될 수도 있습니다. 이를 “zombie APIs”라고 부르기도 합니다. 이러한 API는 관리 감독 없이 운영되며 기업 내 모든 사람에게 숨겨져 있습니다.
자동화된 API discovery 도구를 사용하면 API가 배포된 위치, 민감한 데이터를 포함할 수 있는 API, 보안 취약점 등 현재 에코시스템에 대한 전반적인 관점을 구축할 수 있습니다. 일반적으로 API discovery 후에는 OpenAPI 사양을 생성하고 내보내서 API를 중앙 API Gateway로 마이그레이션하고 개발자 포털 또는 API 카탈로그에 추가할 수 있습니다.
3. API 프로토콜: SOAP, REST, GraphQL을 위한 API 보안
컴퓨팅의 다른 모든 측면과 마찬가지로 API 기술도 지난 25년 동안 개발자들이 성능과 안정성을 개선하기 위한 방법을 모색하면서 변화해 왔습니다. API의 설계 철학과 데이터 표현 방식은 물론 데이터와 트래픽을 보호하는 방식도 함께 발전해 왔습니다. 널리 사용되는 API 아키텍처의 타임라인은 대략 다음과 같습니다:
SOAP (1998-2010) → REST (2010-now) → GraphQL (2020-future)
3-1. SOAP APIs
SOAP(Simple Ojbects Access Protocol) API는 디지털 서명과 XML 형식 데이터의 암호화를 사용하여 메시지 수준에서 보안을 적용합니다. 메시지 수준 보안은 일반적으로 REST API 아키텍처 스타일(아래)의 보안보다 더 포괄적입니다. 그러나 이식성이 뛰어나다는 평가를 받고 있지만, 메시지 수준 보안은 이제 레거시 웹 서비스에서만 볼 수 있습니다.
3-2. REST APIs
지난 10년 동안 REST(representational state transfer)는 API의 가장 인기 있는 아키텍처 스타일이 되었습니다. 오늘날 대부분의 웹 API는 REST API입니다. REST에서 리소스는 고유한 HTTP URI로 식별되며, 액세스 제어 규칙은 HTTP 동사와 HTTP URI 간의 조합을 기반으로 합니다.
3-3. GraphQL APIs
GraphQL은 새롭게 떠오르는 API용 쿼리 언어입니다. 프론트엔드 개발자가 자신의 애플리케이션에 가장 적합한 방식으로 API 쿼리를 사용자 지정할 수 있도록 하여 제어권을 부여합니다. 모든 리소스는 단일 URI를 통해 액세스됩니다. 이러한 유연성과 제어 기능으로 인해 GraphQL은 점점 더 인기를 얻고 있습니다.
SOAP와 REST에는 검증된 액세스 제어 방법론이 있지만, GraphQL API 전반에 걸쳐 액세스 제어를 적용할 수 있는 방법은 아직 확립되지 않았습니다.
3-4. 일반적인 위협: SOAP과 REST, GraphQL API 비교
이 차트에는 각 API 유형 또는 아키텍처 스타일별로 가장 일반적인 공격과 취약점이 나열되어 있습니다.
3-5. 모범 사례: SOAP와 REST, GraphQL API 비교
여기에서는 각 유형의 API로 보안을 구현하기 위한 모범 사례를 요약하여 설명합니다.
| SOAP APIs | REST APIs | GraphQL APIs | |
| Access control | ✓ | ✓ | |
| Input validation | ✓ | ||
| Encryption | ✓ | ||
| SSL/TLS | ✓ | ||
| Single sign-on (SSO) | ✓ | ||
| Rate limiting | ✓ | ||
| Tokenization | ✓ | ||
| Implement authentication | ✓ | ✓ | |
| SAML authentication | ✓ | ||
| Third-party authorization | ✓ | ||
| Validate API parameters | ✓ | ||
| Query timeouts | ✓ | ✓ | |
| Limit query depth | ✓ | ||
| Restrict access to resources | ✓ | ||
| Use pagination | ✓ |
4. 다양한 배포를 위한 API 보안
클라우드, 온프레미스 또는 하이브리드 배포에 관계없이 API를 구축하는 데 사용하는 기술 스택에 따라 API를 보호하는 방법이 달라집니다.
5. API 보안 계층
API를 보호하는 가장 일반적인 방법 중 하나는 각 계층에서 서로 다른 유형의 보호를 적용하는 다계층 방어 전략을 사용하는 것입니다. 이를 흔히 “심층 방어” 접근 방식이라고 합니다.
이러한 방어는 성벽과 같은 보호 기능을 상상할 수 있습니다. API discovery 및 WAF와 같은 경계 방어는 가장 바깥쪽의 보호 계층을 제공합니다. 그러나 일단 게이트를 통과하고 나면 도중에 여러 체크포인트에서 제지당하게 됩니다. 이러한 체크포인트는 성을 가로지르는 측면 이동을 방지하고 성의 다른 부분에 접속할 수 있는 올바른 자격 증명을 가지고 있는지 확인하는 데 도움이 됩니다. 최신 애플리케이션 아키텍처에서는 API Gateway 및 기타 지점에서의 세분화된 액세스 제어와 추가 신원 확인이 이러한 체크포인트 역할을 합니다.
아래 다이어그램은 트래픽이 애플리케이션 아키텍처를 통과할 때 API와 애플리케이션을 점진적으로 보호하기 위해 이러한 다양한 계층이 어떻게 쌓이는지 보여줍니다. 각 계층에는 API를 보호하기 위해 배포할 수 있는 다양한 기술이 포함되어 있습니다.
6. API 보안 모범 사례
위에 설명한 방법 외에도 여러 경로에서 강력한 API 보안을 달성하기 위한 몇 가지 모범 사례를 소개합니다.
6-1. API Gateway 및 웹 애플리케이션 방화벽
API Gateway는 API 요청을 수락하여 적절한 서비스로 연결합니다. API Gateway를 배포하면 API 트래픽을 제어, 모니터링 및 보호할 수 있습니다. 하지만 API Gateway 뒤에 있는 API는 여전히 침해에 취약합니다. API Gateway의 보안을 강화하려면 공격 및 기타 악성 트래픽을 차단하는 WAF를 배포하는 것을 고려하세요.
6-2. 암호화
암호화는 텍스트를 “scrambled” 형태로 인코딩하여 인코딩을 디코딩하지 않고는 원본 텍스트를 읽을 수 없도록 하는 프로세스입니다. 암호화의 모범 사례는 end-to-end encryption(E2EE)로, 데이터가 사용자에서 앱으로, 그리고 다시 앱으로 전달될 때 완전히 암호화합니다. 데이터는 암호 해독 키를 통해서만 볼 수 있으므로 의도하지 않은 사용자의 액세스를 제한할 수 있습니다.
원치 않는 액세스를 더욱 제한하기 위해 웹사이트는 mutual TLS(mTLS)를 사용하여 인증 기관(CA)이 서명한 공개 인증서와 개인 키를 사용하여 클라이언트와 자신을 인증합니다. SSL/TLS 개인 키는 액세스를 인증, 암호화 및 무결성을 확인하는 데 사용됩니다. 이러한 상호 인증은 데이터의 기밀성과 유효성을 모두 보호합니다. 개인 키가 손상되면 공격자는 유효한 사용자를 사칭하거나(네트워크 트래픽을 가로채 수정), 네트워크를 통과하는 트래픽을 실시간으로 기록한 후 오프라인에서 암호를 해독할 수 있습니다.
Let’s Encrypt(무료, 자동화된 개방형 CA)를 사용하여 인증서를 발급하는 방법에 대한 지침은 NGINX로 무료 Let’s Encrypt SSL/TLS 인증서 사용을 참조하세요.
6-3. 인증 및 권한 부여를 위한 OAuth 및 OpenID 연결
OAuth는 웹사이트와 같은 리소스 소유자가 승인된 third-party 인증 서버에서 액세스 토큰을 획득한 클라이언트의 리소스 액세스를 허용하기 위해 널리 사용되는 오픈 소스 표준입니다.
OAuth 2.0은 인증에 대한 업데이트된 업계 표준입니다. 이 프로토콜은 HTTP 서비스(예: Facebook)에서 API를 활성화하여 동의된 액세스를 허용하고 다양한 리소스를 통해 사용자 데이터를 쉽게 해석할 수 있게 해줍니다. 이러한 리소스는 사용자의 자격 증명을 사용하지 않고 대신 사용자 이름과 비밀번호 토큰을 사용하여 사이트 간에 공유됩니다.
OAuth 2.0 프레임워크의 상단에 위치하며 ID 토큰으로 확장되는 OpenID Connect라는 추가 Id 계층을 통해 OAuth를 강화할 수 있습니다. ID 토큰을 사용하여 OpenID Connect는 사용자를 인증할 수 있습니다.
OAuth 2.0과 OpenID Connect의 결합된 권한 부여(AuthN) 및 인증(AuthZ) 방법을 통해 강력한 보안을 달성할 수 있습니다.
6-4. 모니터링, 감사 및 로깅
OWASP API Security Top 10에서 API10이 강조한 바와 같이, 모니터링과 로깅이 불충분하면 공격에 대한 구멍이 생길 수 있습니다.
모니터링 도구는 애플리케이션 성능에 대한 유용한 정보를 제공합니다. API에서 발생하는 모든 활동은 보안 이벤트로 간주되어 기록됩니다. 그런 다음 로그 파일에서 승인되지 않은 활동을 검사할 수 있습니다.
6-5. API 보안 을 위한 제로 트러스트
기존의 보안 모델은 정해진 보안 경계 내에서 작동하는 사용자, 애플리케이션, 데이터, 디바이스를 신뢰할 수 있다고 가정합니다. 제로 트러스트 접근 방식은 애플리케이션 구성 요소와 인프라가 온프레미스, 하이브리드, 멀티 클라우드 환경에 분산되어 있는 오늘날의 애플리케이션에는 보안 경계가 없으며 따라서 신뢰할 수 있는 ‘내부자’와 같은 개념이 존재하지 않는다는 점을 인식합니다. 모든 요소를 잠재적인 보안 위협으로 간주하고 모든 작업에 대해 인증 및 권한 부여 증명을 요구합니다.
7. NGINX의 지원 방법
NGINX는 API를 보호하고 지속적인 보호를 보장하기 위한 다양한 솔루션을 제공합니다:
- 앱 및 API 보안 – 포괄적인 보호 기능으로 보안 침해를 줄이고 악의적인 사용자에 대한 조직의 노출을 제한합니다. Layer 7(애플리케이션 계층) 공격 보호, End-to-End 암호화, Single Sign-On(SSO), elliptic curve 암호화, API 인증, DDoS 완화 등의 이점을 누릴 수 있습니다.
- 보안 API 연결 – 모든 환경(클라우드, 온프레미스, Edge)에서 비공개, 파트너, 외부 API를 관리, 모니터링, 제어 및 보호합니다. API Connectivity 솔루션의 제품에는 NGINX Plus(엔터프라이즈급 API Gateway로 배포 가능), NGINX App Protect(WAF 및 DoS 보호), NGINX Management Suite API Connectivity Manager가 포함됩니다.
- Kubernetes용 제로 트러스트 보안 – 복잡성과 오버헤드를 추가하지 않고 Edge에서 클라우드에 이르기까지 Kubernetes 앱과 API를 보호합니다. 제품에는 NGINX Ingress Controller, NGINX App Protect(WAF 및 DoS 보호)가 포함됩니다.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 논의하십시오.
NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.