API 보안 모범 사례로 API 최적화

엔터프라이즈 비즈니스는 계속해서 디지털화된 클라우드 기반 IT 인프라로 이동하고 있습니다. 디지털 시스템은 기존의 온프레미스 시스템과 비교했을 때 전례 없는 유연성, 확장성, 속도를 제공합니다.

그러나 디지털 인프라는 소프트웨어 애플리케이션 간 및 애플리케이션과 최종 사용자 간의 데이터 전송을 용이하게 하기 위해 애플리케이션 프로그래밍 인터페이스 (API)에 크게 의존합니다. 대부분의 웹 및 모바일 앱의 백엔드 프레임워크인 API는 인터넷에 연결되어 있으므로 공격에 취약합니다. 또한 많은 API가 민감한 데이터를 저장하고 전송하기 때문에 정보가 잘못된 사람의 손에 들어가는 것을 방지하기 위해 강력한 보안 프로토콜과 세심한 모니터링 관행이 필요합니다.

API 보안은 조직이 API에 대한 악의적인 공격과 오용을 방지하기 위해 사용하는 일련의 관행 및 제품을 말합니다. API 에코시스템의 복잡성, IoT 플랫폼의 성장, 조직이 활용하는 API의 엄청난 양(평균 약 20,000개(ibm.com 외부 링크))을 고려할 때, API 보안에 대한 이해는 점점 더 어려워지고 있으며 그 필요성도 점점 더 커지고 있습니다.

API는 조직의 IT 리소스와 타사 소프트웨어 개발자 사이 또는 IT 리소스와 개인 사이에 위치하여 프로세스 엔드포인트에서 데이터와 정보를 제공합니다. 이러한 엔드포인트에서 회사 및 사용자 데이터는 다음과 같은 다양한 유형의 공격 및 보안 위험에 취약합니다.

• 인증 기반 공격: 해커들이 사용자 암호를 추측하거나 도용하거나 취약한 인증 절차를 악용하여 API 서버에 액세스하려고 시도하는 공격입니다.
• 중간자 공격: 악의적인 공격자가 API 간의 요청 및/또는 응답을 가로채 데이터(예: 로그인 자격 증명 또는 결제 정보)를 훔치거나 수정하는 공격입니다.
• 코드 주입/삽입 공격: 해커가 데이터를 읽고 변환하는 API 인터프리터의 약점을 악용하여 API 요청을 통해 유해한 스크립트(허위 정보 삽입, 데이터 삭제 또는 공개, 앱 기능 방해)를 전송하는 공격입니다.
  
  
• 서비스 거부(DoS) 공격: 수많은 API 요청을 전송하여 서버를 다운시키거나 속도를 저하시키는 공격입니다. DoS 공격은 분산 서비스 거부(DDoS) 공격의 형태로 여러 공격자가 동시에 가하는 경우가 많습니다.
• 손상된 개체 수준 인증(BOLA) 공격: 사이버 범죄자가 API 엔드포인트에서 개체 식별자를 조작하여 사용자 데이터에 무단으로 액세스하는 것을 목적으로 합니다. 이 문제는 API 엔드포인트가 사용자가 일반적으로 액세스해서는 안 되는 레코드에 액세스할 수 있도록 허용할 때 발생합니다. BOLA 공격은 적절한 개체 수준 권한 부여 검사를 구현하는 것이 어렵고 시간이 많이 소요될 수 있기 때문에 흔히 발생합니다.

이러한 사이버 공격과 기타 유형의 사이버 공격은 오늘날의 역동적인 IT 환경에서 피할 수 없는 일입니다. 또한 사이버 범죄자들이 확산되고 더욱 정교한 해킹 기술에 액세스할 수 있게 됨에 따라 API 보안 프로토콜을 구현하는 것이 기업 데이터 보안에 있어 더욱 중요해질 것입니다.

API를 사용하면 기업은 시스템 간 통합과 데이터 공유를 간소화할 수 있지만, 이러한 상호 연결성으로 인해 사이버 공격에 노출될 가능성도 커집니다. 실제로 대부분의 모바일 및 웹 애플리케이션 해킹은 회사 또는 사용자 데이터에 액세스하기 위해 API를 공격합니다. 해킹되거나 손상된 API는 치명적인 데이터 유출 및 서비스 중단으로 이어질 수 있으며, 이로 인해 민감한 개인, 금융 및 의료 데이터가 위험에 처할 수 있습니다.

다행히 API 보안의 발전으로 악의적인 행위자에 의한 사이버 공격의 영향을 예방하거나 완화할 수 있습니다. 다음은 조직이 컴퓨팅 리소스와 사용자 데이터를 보호하기 위해 활용할 수 있는 11가지 일반적인 API 보안 관행 및 프로그램입니다.

1. API Gateway. API Gateway 설치는 API 액세스를 제한하는 가장 쉬운 방법 중 하나입니다. 게이트웨이는 모든 API 요청에 대한 단일 진입점을 생성하고, 보안 정책을 적용하여 보안 계층 역할을 하며, API 상호 작용을 표준화하는 데 도움이 되고, 요청/응답 변환, 캐싱 및 로깅과 같은 기능을 제공합니다.
2. 강력한 인증 및 권한 부여. OAuth 2.0, API 키, JWT, OpenID Connect 등과 같은 업계 표준 인증 프로토콜을 사용하면 인증된 사용자만 기업 API에 액세스할 수 있습니다. 또한 역할 기반 액세스 제어를 구현하면 사용자가 사용 권한이 없는 리소스에 액세스하는 것을 방지할 수 있습니다.
3. 암호화 프로토콜. SSL 연결 또는 TLS 암호화 프로토콜(예: HTTP Secure(HTTPS))은 팀이 API와 클라이언트 애플리케이션 간의 통신을 보호하는 데 도움이 됩니다. HTTPS는 모든 네트워크 데이터 전송을 암호화하여 무단 액세스 및 변조를 방지합니다. 저장된 비밀번호와 같은 미사용 데이터를 암호화하면 스토리지에 있는 민감한 데이터를 더욱 안전하게 보호할 수 있습니다.
4. 웹 애플리케이션 방화벽(WAF). WAF는 특히 인젝션 공격, 크로스 사이트 스크립팅(XSS), 크로스 사이트 요청 위조(CSRF)와 같은 일반적인 웹 앱 공격으로부터 기업 API를 위한 추가 보호 계층을 제공합니다. WAF 보안 소프트웨어는 들어오는 API 요청을 분석하고 악성 트래픽이 서버에 도달하기 전에 차단할 수 있습니다.
5. 데이터 유효성 검사. 사람들이 전화 통화를 선별하고 알 수 없는 발신자의 첨부 파일을 열지 않는 것과 같은 방식으로 조직은 서버가 수락하는 모든 것을 검사하고 대용량 데이터 또는 콘텐츠 전송(소비자 포함)을 거부해야 합니다. XML 또는 JSON 스키마 유효성 검사를 사용하고 매개 변수를 확인하는 것도 공격을 방지하는 데 도움이 될 수 있습니다.
6. 속도 제한. 이는 사용자 또는 IP 주소가 특정 시간 동안 수행할 수 있는 요청 수를 제한하여 무차별 암호 대입 및 DoS 공격으로부터 리소스를 보호합니다. 속도 제한은 요청이 빨리 처리되도록 하며, 아무도 유해한 요청으로 시스템을 압도할 수 없도록 합니다.
7. 보안 테스트. 보안 테스트를 수행하려면 개발자가 API 클라이언트를 사용하여 표준 요청을 제출하여 시스템 응답의 품질 및 정확성을 평가해야 합니다. 취약점을 식별하고 해결하기 위해 침투 테스트, 인젝션 테스트, 사용자 인증 테스트, 매개 변수 변조 테스트 등과 같은 정기적인 API 보안 테스트를 수행하면 공격자가 취약점을 악용하기 전에 팀이 취약점을 수정하는 데 도움이 됩니다.
8. API 모니터링 및 패치. 다른 소프트웨어 애플리케이션 또는 시스템과 마찬가지로 정기적인 모니터링과 유지 관리는 API 보안을 유지하는 데 필수적입니다. 비정상적인 네트워크 활동을 주시하고 최신 보안 패치, 버그 수정 및 새로운 기능으로 API를 업데이트합니다. 모니터링에는 오픈 웹 애플리케이션 보안 프로젝트(OWASP) 상위 10개 목록에 포함된 것과 같은 일반적인 API 취약점에 대한 인식과 대비도 포함되어야 합니다.
9. 감사 및 로깅. 포괄적인 최신 감사 로그를 보관하고 자주 검토하면 조직은 모든 사용자 데이터 액세스 및 사용을 추적하고 모든 API 요청을 기록할 수 있습니다. API 활동을 파악하는 것은 어려울 수 있지만, 감사 및 로깅 절차를 구현하면 팀이 데이터 유출 또는 규정 준수 실패 후 단계를 다시 추적해야 할 때 시간을 절약할 수 있습니다. 또한 감사 로그는 정상적인 네트워크 동작에 대한 기록을 제공하기 때문에 이상 징후를 더 쉽게 발견할 수 있습니다.
10. 할당량 및 스로틀링. 속도 제한과 마찬가지로 스로틀링은 시스템이 받는 요청 수를 제한합니다. 하지만 사용자 또는 클라이언트 수준이 아닌 서버/네트워크 수준에서 작동합니다. 스로틀링 제한 및 할당량은 API의 백엔드 시스템 대역폭을 보호하기 위해 API를 초당 특정 수의 호출이나 메시지로 제한합니다. 할당량과 관계없이 시스템 호출의 양이 증가하면 남용 및/또는 프로그래밍 오류를 표시할 수 있으므로 시간이 지남에 따라 시스템 호출의 양을 평가하는 것이 중요합니다.
11. 버전 관리 및 문서화. API 소프트웨어의 모든 새 버전에는 이전 버전의 보안 격차를 보완하는 보안 업데이트 및 버그 수정이 함께 제공됩니다. 또한 적절한 문서화 관행이 없으면 사용자가 실수로 오래되거나 취약한 버전의 API를 배포할 수 있습니다. 문서에는 입력 매개변수, 예상 응답 및 보안 요구 사항을 명확하게 명시하는 등 철저하고 일관된 내용이 포함되어야 합니다.

기존의 API 보안 조치 중 AI는 API를 강화하기 위한 새롭고 잠재적으로 강력한 도구로 부상했습니다. 예를 들어, 기업은 API 에코시스템에서 이상 징후 탐지를 위해 AI를 활용할 수 있습니다. 팀은 정상적인 API 동작의 기준을 설정한 후 AI를 사용하여 비정상적인 액세스 패턴이나 고빈도 요청과 같은 시스템 편차를 식별하고 잠재적인 위협에 플래그를 지정하며 공격에 즉시 대응할 수 있습니다.

AI 기술은 자동화된 위협 모델링을 가능하게 할 수도 있습니다. AI는 과거 API 데이터를 사용하여 위협 모델을 구축하여 악의적인 공격자가 이를 악용하기 전에 취약성과 위협을 예측할 수 있습니다. 대량의 인증 기반 공격을 처리하는 조직은 AI를 사용하여 생체 인식과 같은 고급 사용자 인증 방법을 설치하여 공격자가 무단으로 액세스하는 것을 더 어렵게 만들 수 있습니다.

또한 AI 기반 도구는 API 보안 테스트 프로토콜을 자동화하여 수동 테스트보다 더 효율적이고 효과적으로 보안 격차와 위험을 식별할 수 있습니다. API 에코시스템이 성장함에 따라 AI 기반 보안 프로토콜도 성장하고 있습니다. AI를 사용하면 많은 API를 동시에 모니터링하고 보호할 수 있어 API 자체만큼이나 확장 가능한 API 보안을 구현할 수 있습니다.

API 보안의 중요성은 아무리 강조해도 지나치지 않습니다. 디지털 혁신 시대로 접어들면서 보안 위협과 악의적인 행위자는 진화하고 있고 이에 따라 API에 대한 의존도는 계속 증가할 것입니다. 하지만 IBM API Connect와 같은 API Management 툴을 사용하여 조직은 전체 라이프사이클 동안 API가 관리되고 안전하며 규정을 준수하는지 확인할 수 있습니다.

API 보안은 결코 일회성 작업이 아닙니다. 오히려 기업은 이를 새로운 기술과 솔루션에 대한 경계심, 능숙함, 개방성을 필요로 하는 지속적이고 역동적인 프로세스로 보아야 합니다. 사용자는 기존 API 보안 관행과 Noname Advanced API Security for IBM과 같은 새로운 AI 기반 접근 방식을 결합하여 IT 리소스의 보안을 최대한 유지하고 소비자와 기업 모두를 보호할 수 있습니다.