Top 12 Tips For API Security
www.youtube.com
Top 12 this For API Security
요즘 대부분의 어플리케이션은 주로 API 를 통해 데이터를 처리하고 외부 시스템과의 통신을 중개하는 역할을 하는데요.
API Security 를 신경쓰지 않으면 데이터 노출과 공격을 통해 비즈니스 운영에 심각한 차질을 불러올 수 있을거에요. 그래서 API Security 에 신경써야합니다.
다음은 ByteBytegGo 에서 알려주는 API Security 를 위한 12가지 팁입니다. 원문 링크도 첨부해둘게요~
1) Use HTTPS
What:
HTTPS는 HTTP에 SSL/TLS 보안 프로토콜을 적용한 것으로 데이터가 전송되는 동안 암호화되어 클라이언트와 서버 간에 안전하게 데이터를 전송할 수 있도록 해줍니다.
암호화는 데이터가 도난, 도청 (Eavesdropping), 변조 (Man-in-the-Middle, MiTM) 되는 것을 방지하며, 이는 사용자의 개인정보, 로그인 자격 증명 및 기타 민감한 정보를 안전하게 유지하는 역할을 합니다.
When:
API를 통해 데이터를 전송할 때는 항상 HTTPS 를 사용하는 것이 좋습니다.
How:
HTTPS를 구현하는 과정은 다음과 같습니다:
1. SSL/TLS 인증서 획득: 도메인에 대한 SSL/TLS 인증서를 획득해야 합니다. 이 인증서는 공인된 인증 기관(CA)으로부터 구매하거나 Let’s Encrypt와 같은 서비스를 통해 무료로 발급받을 수 있습니다.
2. 서버 설정: 서버가 SSL/TLS 인증서를 사용하도록 설정해야 합니다. 이는 웹 서버 소프트웨어에 따라 다르지만, 일반적으로 인증서 파일을 서버에 설치하고, 서버 설정 파일에서 HTTPS를 활성화하는 과정을 포함합니다.
3. 리디렉션 구현: 모든 HTTP 요청을 HTTPS로 리디렉션하도록 서버를 설정합니다. 이렇게 하면 사용자가 HTTP를 통해 접근하려 할 때 자동으로 보안 연결로 전환됩니다.
4. HSTS 설정: 웹 서버에서 HTTP Strict Transport Security(HSTS)를 활성화하여 브라우저가 해당 서버와의 통신을 오직 HTTPS를 통해서만 수행하도록 합니다. 이는 공격자가 사용자를 HTTP로 리디렉트 시키려는 시도를 차단하는 데 도움이 됩니다.
5. API 클라이언트 업데이트: API 클라이언트가 HTTPS를 통해서만 데이터를 요청하도록 업데이트합니다. 이는 API를 사용하는 모든 애플리케이션에 적용되어야 합니다.
2) Use OAuth 2.0:
What:
OAuth 2.0 은 애플리케이션 간의 안전한 권한 부여를 위해 널리 사용됩니다.
OAuth 2.0은 클라이언트 애플리케이션이 사용자의 대리인으로서 리소스 서버에 접근할 수 있도록 토큰 기반 인증을 사용하는 권한 부여 프레임워크입니다. 사용자는 자신의 로그인 정보를 클라이언트에게 직접 제공하지 않고, 대신 OAuth 2.0 프로세스를 통해 클라이언트에게 엑세스 토큰을 발급합니다.
클라이언트는 이 토큰을 통해서 리소스 서버에 제한된 접근을 해서 필요한 정보를 가져올 수 있습니다.
When:
구글 로그인과 같은 기능을 만들고 싶을 때
사용자가 다른 서비스 (e.g 구글, 네이버, 카카오 등) 의 기능을 사용하려고 할 때
OAuth 2.0 은 구글과 같은 타사 서비스를 통한 로그인 기능 뿐 아니라 자체 서버 및 서비스 간의 인증과 권한 부여를 할 때도 매우 유용하니 자사의 마이크로서비스 아키텍처에서도 데이터를 공유하고 기능을 수행하는 경우에도 OAuth 2.0 을 사용하는 것이 유용할 수 있습니다.
How:
OAuth 2.0 구현의 핵심 단계는 다음과 같습니다:
1. 클라이언트 등록: 애플리케이션을 OAuth 2.0을 제공하는 서비스에 클라이언트로 등록합니다. 이 과정에서 클라이언트 ID와 클라이언트 비밀번호가 발급되며, 리다이렉션 URI가 설정됩니다.
2. 권한 요청: 사용자가 클라이언트 애플리케이션을 사용하여 로그인을 시도할 때, 애플리케이션은 사용자를 권한 서버의 로그인 페이지로 리다이렉션합니다.
3. 사용자 인증 및 권한 부여: 사용자가 권한 서버에서 로그인하고 클라이언트 애플리케이션에 특정 권한을 부여합니다.
4. 액세스 토큰 발급: 사용자가 권한을 부여하면, 권한 서버는 클라이언트 애플리케이션에 액세스 토큰을 발급합니다.
5. 리소스 접근: 클라이언트는 발급받은 토큰을 사용하여 리소스 서버에 접근하고, 사용자 대신 작업을 수행할 수 있습니다.
3) WebAuthn:
What:
WebAuthn (Web Authentication)은 API 보안을 위한 최신 인증 표준입니다. 이 표준은 웹 기반 인증을 보다 강화하고 사용자 친화적으로 만드는 방법을 제공하는 방법입니다.
이는 사용자가 물리적인 보안 장치(예: 지문, 얼굴 인식, 보안 키 등)를 사용하여 웹사이트에 로그인할 수 있도록 지원합니다.
기존의 비밀번호 기반 인증 시스템의 보안 취약점을 해결하고, 보다 간편하고 안전한 인증 방법을 제공하려는 목적을 가지고 있습니다.
When:
사용자가 비밀번호를 기억하거나 입력할 필요 없이, 더 빠르고 안전하게 로그인하길 원할 때.
기존의 인증 방법과 함께 추가 보안 계층을 제공하고자 할 때.
피싱 및 기타 인증 공격을 방지하고자 할 때: (WebAuthn은 사용자 인증 정보의 도난을 방지하고, 인증 정보가 사용자의 물리적 장치에 저장되어 있기 때문에 외부에 노출되지 않습니다.)
How:
WebAuthn을 구현하는 단계는 다음과 같습니다:
1. 사용자는 자신의 물리적 장치(e.g YubiKey, 지문 스캐너 등)를 사용하여 웹사이트에 자신을 등록합니다. 이 과정에서 공개 키와 개인 키가 생성됩니다. 개인 키는 사용자의 장치에 안전하게 저장되며, 공개 키는 서버에 저장됩니다.
2. 사용자가 웹사이트에 로그인할 때, 웹사이트는 사용자의 장치로 인증 요청을 보냅니다. 사용자의 장치는 사용자의 동의(지문 인식, PIN 입력 등)를 받아 개인 키를 사용하여 요청을 서명하고, 이 서명을 웹사이트로 전송합니다.
3. 웹사이트 서버는 받은 서명을 사용자의 공개 키로 검증하여 인증을 완료합니다. 이 과정에서 사용자의 개인 정보는 전송되지 않으므로 보안이 유지됩니다.
4) Use Leveled API Keys
What:
API 키에 다양한 권한 수준을 부여하여 더 세밀하고 안전한 접근 제어를 가능하게 하는 방법입니다.
Leveled API Keys는 API 사용자에게 부여되는 키로, 각 키는 설정된 권한 수준에 따라 API의 특정 부분에 대한 접근을 허용합니다. 이는 각 키가 일정한 권한 범위 내에서만 작동하도록 하여, 보안을 강화하고 불필요하거나 위험한 데이터 접근을 최소화합니다. 예를 들어, 일부 키는 읽기 전용 액세스를 허용하는 반면 다른 키는 데이터를 변경할 권한을 부여할 수 있습니다.
When:
데이터 노출 위험을 최소화할 때 (특정 사용자 또는 서비스가 필요로 하는 기능에만 접근할 수 있도록 하여 데이터 노출을 제한하고 싶을 때 유용합니다.)
다양한 사용자 또는 개발자 그룹에게 서로 다른 접근 권한을 부여해야 할 때.
API를 공개적으로 제공할 때 (공개 API를 제공하는 경우, 사용자별로 다른 권한 수준을 설정하여 보안을 강화할 수 있습니다.)
How:
Leveled API Keys를 구현하는 단계는 다음과 같습니다:
1. 먼저, API에 대한 다양한 접근 권한 레벨을 정의합니다. 이는 읽기 전용, 쓰기 권한, 관리자 권한 등으로 나눌 수 있습니다.
2. 각 키에 대해 특정 권한을 설정하고, 해당 키를 사용자 또는 애플리케이션에 할당합니다.
3. API 서버에 접근 제어 로직을 구현하여, 각 요청이 적절한 키를 통해 이루어졌는지 확인하고, 해당 키가 허용하는 작업만 수행되도록 합니다.
4. 모든 API 요청을 모니터링하고 로깅하여, 비정상적인 접근 시도나 권한 남용을 감지할 수 있도록 합니다.
그리고 Leveled API Keys를 사용할 때는 키가 노출되지 않도록 주의해야 하며, 정기적으로 키를 갱신하거나 만료시키는 것이 좋습니다.
5) Implement Authorization (RBAC)
What:
RBAC는 사용자의 역할에 따라 시스템 자원에 대한 접근 권한을 관리하는 방식으로, 사용자를 특정 역할에 할당하고 각 역할에 필요한 권한을 부여하는 방법입니다.
각 역할은 특정 권한을 가지고 있으며, 사용자는 해당 역할에 따라 시스템의 자원을 사용할 수 있는 권한을 부여받습니다. 예를 들어, "관리자" 역할은 시스템 설정 변경 권한을 가질 수 있으며, "사용자" 역할은 정보 조회 권한만을 가질 수 있습니다.
When:
많은 수의 사용자와 다양한 접근 요구 사항을 관리해야 할 때
데이터의 보안을 강화하고, 불필요한 접근으로부터 보호해야 할 때
How:
RBAC을 구현하는 단계는 다음과 같습니다:
1. 시스템에서 필요로 하는 모든 역할을 식별하고 정의합니다. 각 역할은 특정 권한 집합과 연결됩니다.
2. 각 사용자를 적절한 역할에 할당합니다. 사용자는 할당된 역할에 따라 권한을 부여받게 됩니다.
3. 각 역할에 필요한 권한을 정확히 설정합니다. 이는 데이터베이스, 파일 시스템, 네트워크 자원 등에 대한 접근을 포함할 수 있습니다.
4. 시스템은 사용자의 요청이 들어올 때마다 해당 사용자의 역할을 검증하고, 해당 역할에 부여된 권한에 따라 요청을 승인하거나 거부합니다.
5. RBAC 시스템은 사용자의 행위와 권한 변경 사항을 기록하여, 보안 감사 및 규정 준수를 지원합니다.
6) Rate Limiting
What:
Rate Limiting은 사용자 또는 서비스가 일정 시간 동안 API를 호출할 수 있는 횟수를 제한하는 기술입니다. 이 기법은 서버에 과도한 부하가 걸리는 것을 방지하고, DDoS 공격 같은 악의적인 행위를 차단하기 위해 사용됩니다.
Rate Limiting을 적용하면, 각 사용자 ID, IP Address 또는 API Key 별로 요청 허용 횟수를 설정하고, 초과하는 요청은 자동으로 거부하게 됩니다.
When:
시스템이 갑작스러운 트래픽 증가를 겪을 때, 예를 들어 프로모션 기간이나 중요 이벤트 동안.
API를 대상으로 한 DDoS 공격이나 크롤링 등의 악의적인 사용을 막을 때.
모든 사용자가 서비스를 공정하게 이용할 수 있도록 하기 위해.
How:
Rate Limiting을 구현하는 단계는 다음과 같습니다:
1. API 사용 정책을 바탕으로 적절한 Rate Limit 값을 설정합니다. 이 값은 요청의 수, 시간 단위(예: 분, 시간, 일) 및 대상 사용자 또는 IP를 고려하여 결정됩니다.
2. Rate Limiting을 구현하기 위해, 많은 API 게이트웨이 또는 웹 프레임워크에서 지원하는 기능을 활용할 수 있습니다. 예를 들어, Nginx, AWS API Gateway, Kong 등이 있습니다.
3. Rate Limit을 초과하는 요청에 대해 사용자에게 적절한 오류 메시지(예: HTTP 429 Too Many Requests)를 반환하여 통지합니다.
4. Rate Limiting 정책은 시간에 따라 변할 수 있으므로, 지속적인 모니터링과 필요에 따라 조정이 중요합니다.
Rate Limiting을 적용할 때는 너무 엄격하게 제한하면 정상적인 사용자 경험을 저해할 수 있으므로, 사용자의 요구와 서버의 용량을 적절히 고려해야 합니다. 또한, 다양한 사용자나 시스템의 요구를 반영하여 접근하는 리소스의 종류에 따라 여러 레벨의 Rate Limit 을 설정할 수도 있습니다.
7) API Versioning
What:
API의 여러 버전을 관리하고 유지하는 전략으로, 기존의 사용자와 시스템이 새로운 변경 사항으로 인해 영향을 받지 않도록 즉 하위 호환성을 보장합니다.
이를 통해 개발자는 API의 새로운 기능을 추가하거나 변경할 수 있으며, 이전 버전의 API를 계속 사용하려는 사용자에게 영향을 주지 않습니다. 버전 관리는 URL 경로, 헤더, 또는 쿼리 매개변수를 통해 수행될 수 있습니다.
When:
API 에 새로운 기능을 추가하거나 기존 기능을 수정할 때, 기존 사용자에게 영향을 주지 않기 위해 새 버전을 생성할 수 있습니다.
이전 버전의 API를 사용하는 기존 클라이언트와의 호환성을 유지하면서 서비스를 개선하고 싶을 때.
장기적인 미래의 확장성과 유연성을 고려하여 API를 설계할 때.
How:
API Versioning을 구현하는 방법은 여러 가지가 있습니다:
1. URL Versioning: URL 경로에 버전 번호를 포함시켜 다른 버전의 API를 호출할 수 있게 합니다. 예: https://api.example.com/v1/resource
2. Header Versioning: HTTP 헤더를 사용하여 버전 정보를 전달합니다. 클라이언트는 특정 버전을 요청할 때 HTTP 헤더에 버전 정보를 포함시켜 요청을 보냅니다.
3. Query String Versioning: 요청의 쿼리 매개변수를 통해 버전 정보를 전달합니다. 예: https://api.example.com/resource?version=1
API Versioning 을 이용할 땐 각 버전의 API는 명확하게 문서화되어야 합니다. 그리고 오래된 버전의 API 는 언제 어떻게 단계적으로 제거할지에 대한 명확한 정책을 수립하는 것이 좋습니다.
8) AllowListing
What:
이는 특정 사용자, IP Address 또는 API Key 만을 사전에 승인된 목록에 등록하여 해당 소스로부터의 요청만을 허용하는 방식입니다. 그래서 “Deny all, Permit some” 방식이라고도 합니다.
이 방식을 통해 특정 네트워크, 사용자 또는 서비스만이 API에 접근할 수 있도록 제한하여 보안을 강화할 수 있습니다.
When:
중요한 데이터를 다루는 API나, 외부로부터의 접근을 엄격히 제한해야 할 때.
기업 내부 네트워크나 제한된 네트워크에서만 작동해야 하는 서비스의 경우.
의료 등 규제가 많은 산업에서는 데이터 접근을 엄격하게 통제하기 위해서 이 방법을 사용할 수 있습니다.
How:
Allowlisting을 구현하는 방법은 다음과 같습니다:
1. 승인된 IP 주소, 사용자 ID, 디바이스 ID 등의 목록을 생성합니다. 이 목록은 API 보안 게이트웨이 또는 서버 설정에 포함될 수 있습니다.
2. API 접근을 허용할 기준을 설정하고, 이 기준에 맞지 않는 요청은 차단합니다.
3. 보안 게이트웨이나 방화벽을 사용하여 허용된 요청만이 API 서버로 전달되도록 합니다.
4. 보안 상황이 변경될 때마다 allowlist를 검토하고 필요에 따라 업데이트합니다.
AllowListing 은 효과적인 보안 수단이지만, 유연성을 제한할 수 있으므로 너무 엄격하게 적용할 경우 정상적인 사용자의 활동을 방해할 수 있다는 점을 알고 적용해야합니다.
9) Check OWASP API Security Risks
What:
OWASP (Open Web Application Security Project)는 웹 애플리케이션과 API 보안에 대한 연구, 문서화 및 도구를 제공하는 비영리 국제 기구입니다.
이들이 제공하는 API 보안 위험 목록은 개발자와 보안 전문가들이 API를 설계하고 구현할 때 고려해야 할 주요 보안 위험을 정의하므로 따르는 것이 좋습니다.
대표적인 OWASP API Security Top 10 목록은 다음과 같습니다:
Broken Object Level Authorization (BOLA): 객체 수준 권한 검증이 잘못되어 사용자가 권한이 없는 데이터에 접근할 수 있게 되는 취약점입니다.
Broken User Authentication: 인증 메커니즘이 취약하여, 공격자가 사용자의 계정을 도용하거나 세션 토큰을 조작하는 등의 행위를 통해 인증된 사용자처럼 행동할 수 있는 취약점입니다.
Excessive Data Exposure: 개발자가 클라이언트 측에서 데이터를 필터링하도록 의도하거나 구현하지 않아, 민감한 데이터가 노출되는 취약점입니다
Lack of Resources & Rate Limiting: API가 적절한 자원 할당 또는 요청률 제한을 구현하지 않아, 서비스 거부(DoS) 공격에 취약해지는 경우입니다.
Broken Function Level Authorization: 함수 수준에서의 권한 부여가 잘못되어, 사용자가 권한이 없어야 할 API 기능을 사용할 수 있게 되는 취약점입니다
Mass Assignment: 클라이언트가 보내는 데이터를 제대로 필터링하지 않아, 공격자가 의도치 않은 방식으로 데이터 객체의 속성을 변경할 수 있는 취약점입니다
Security Misconfiguration: 보안 구성이 잘못되어 기본 설정, 불완전한 또는 잘못된 구성,불필요하게 활성화된 기능 등으로 인해 발생하는 취약점입니다
Injection: SQL, NoSQL, LDAP 주입 등 사용자의 데이터가 API에 전달될 때 적절한 처리가 이루어지지 않아, 공격자가 악의적인 코드를 주입할 수 있는 취약점입니다
Improper Assets Management: API 버전 관리와 호스팅이 적절히 이루어지지 않아, 구버전 API나 미사용 API가 공격 대상이 되는 경우입니다
Insufficient Logging & Monitoring: 로깅과 모니터링이 부족하여 보안 침해 사고를 식별하고 대응하는 데 필요한 시간이 지연되거나, 침해 사실을 인지하지 못하는 취약점입니다.
When:
API 설계 초기 단계에서 미리 적용하는 것이 좋습니다.
위험 요소가 추가될 때마다 대응하는 것이 좋습니다.
How:
1. OWASP 웹사이트나 관련 문서에서 최신 API 보안 위험 목록을 참조합니다.
2. 개발 중이거나 이미 구현된 API를 대상으로 각 위험 요소를 평가하여 취약점을 분석합니다.
3. 각 위험 요소에 대해 특정 완화 전략을 수립하고 적용합니다. 이에는 코딩 가이드라인, 보안 설정, 제3자 보안 도구의 사용 등이 포함될 수 있습니다.
10) Use API Gateway
What:
API Gateway는 클라이언트와 서비스 간의 인터페이스 역할을 하는 서버입니다. 이는 모든 인바운드 API 요청을 수신하고, 이 요청들을 적절한 내부 서비스로 라우팅하는 역할을 합니다. 또한, API Gateway는 Authentication, Rate Limiting, Caching, Logging, Monitoring 같은 중요한 기능을 통합하여 API의 성능과 보안을 향상시킵니다.
When:
서비스가 여러 작은 마이크로서비스로 분할되어 있을 때, 각 서비스 간의 통신을 조율하고 관리하는 데 API Gateway 를 사용할 수 있습니다.
API에 대한 보안 강화가 필요할 때 API Gateway 에서 인증 및 인가, API 키 검증 등의 보안 기능을 통해 비인가 접근을 차단할 수 있습니다.
트래픽이 많은 API를 운영할 때 API Gateway 를 통해 요청의 속도 제한이나 캐싱을 통해 서버 부하를 줄이고 성능을 개선할 수 있습니다.
API Gateway 를 이용해서 API 사용 패턴을 모니터링하고 로깅하여, 보안 위협을 식별하고 성능 문제를 해결할 수 있습니다.
How:
1. API Gateway 소프트웨어를 선택하고 설치한 후, 특정 네트워크 환경에 맞게 구성합니다.
2. 클라이언트 요청을 적절한 백엔드 서비스로 라우팅하기 위한 규칙을 정의합니다.
3. 인증, 인가, API 키 관리, SSL/TLS 등의 보안 메커니즘을 설정합니다.
4. 서비스의 성능을 유지하고 과도한 트래픽에 대응하기 위해 요청 속도 제한 및 캐싱 규칙을 구현합니다.
5. API 사용 상황을 모니터링하고 로그를 수집하여 보안과 성능을 지속적으로 모니터링합니다.
11) Error Handling
What:
Error Handling은 API에서 발생하는 다양한 오류 조건을 식별하고, 이에 대한 적절한 응답을 생성하는 프로세스입니다. 이는 클라이언트가 API 요청을 보내면서 발생한 문제에 대해 적절한 안내를 받을 수 있도록 해줍니다.
단순히 "Internal Server Error" 라고 모호한 메시지를 보내는 것보다 "Failed to retrieve users data. Please check that your are authenticated and have sufficient permissions" 라고 응답주는 것이 문제 해결에 더 도움을 주는 메시지일 겁니다.
When:
사용자가 부정확한 요청을 보내거나, 서버 측의 문제로 인해 예기치 않은 오류가 발생할 때.
사용자가 오류를 이해하고 문제를 해결할 수 있도록 명확하고 유용한 오류 메시지를 제공하기 위해 사용할 수 있습니다.
How:
1. API에서 예외를 적절하게 처리하고, 클라이언트에게 적절한 오류/상태 코드와 함께 응답을 반환하도록 합니다.
2. 클라이언트가 오류를 이해하고 문제를 해결할 수 있도록 명확하고 유용한 오류 메시지를 제공하도록 합니다.
3. 오류 메시지가 클라이언트에게 민감한 정보를 노출하지 않도록 제어하고, 보안 취약점을 최소화 하도록 합니다. (예로, 스택 트레이스 같은 정보는 노출하지 않는 것이 좋습니다.)
4. 발생한 오류를 기록하고 모니터링하여 시스템의 문제를 파악하고 해결할 수 있도록 구성하도록 합니다.
5. 적절한 HTTP 상태 코드를 사용하여 클라이언트에게 오류 유형을 알려줘야 합니다.
12) Input Validation
What:
Input Validation은 클라이언트로부터 수신한 입력 데이터의 유효성을 확인하는 과정입니다. 이는 입력 데이터가 기대한 형식과 구조에 부합하는지 확인하여, 악의적인 사용자로부터의 공격을 방어하고 시스템의 안정성을 유지할 수 있습니다.
When:
사용자가 제공한 입력 데이터를 처리할 때, 데이터의 유효성을 검증하여 악의적인 데이터를 거부할 수 있습니다.
How:
1. 일반적인 입력 유효성 검사를 위한 라이브러리를 사용하여, 입력 데이터의 형식과 구조를 확인할 수 있습니다.
2. 정규 표현식을 사용하여 입력 데이터의 패턴을 확인하고, 유효성을 검증할 수 있습니다.
3. 특수 문자나 SQL 삽입 등의 공격을 방어하기 위해, 입력 데이터에 허용되지 않는 문자나 문자열을 거부할 수 있습니다.
4. 입력 데이터의 길이를 제한하여, 과도한 데이터 양으로 인한 시스템 부하를 방지하고 데이터 무결성을 유지할 수 있습니다.
5. 입력 데이터의 유형을 명시적으로 캐스팅하여, 의도하지 않은 형변환에 의한 보안 취약점을 방어할 수 있습니다.
https://www.youtube.com/watch?v=6WZ6S-qmtqY
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 5월 6일 오전 8:26