비즈니스 보호는 API 보호와 같습니다.

API는 애플리케이션 계층에서 추상화하는 기능을 통해 가치를 창출합니다. 예를 들어, API를 사용하여 내부 시스템 및 데이터에 대한 액세스를 추상화하면 기존 IT 시스템에 대한 액세스를 간소화하고 자동화하는 방법을 제공합니다. API는 또한 생태계와 파트너 간의 통합을 달성하는 수단입니다. API는 오늘날 자동화 및 오케스트레이션의 주요 수단이기도 하며, 이로 인해 성공적인 디지털 혁신 여정의 핵심 기술 중 하나가 되었습니다. 따라서 API는 혁신, 효율적인 실행, 수익 창출의 원천으로서 기업의 전략적 요소가 되었습니다.

수익화 

디지털 경제에서는 수익을 창출할 수 있는 모든 것은 결국 수익화될 것입니다. 이는 특히 API에 해당하며, 연구에 따르면 API 경제는 강력합니다.

• 10개 기업 중 1개 이상(11%)이 API 및 API 관련 구현에서 매출의 절반 이상을 창출합니다. ( API의 비즈니스 가치 ) 
• 무려 59%의 기업이 조직 수익의 26%~50%를 API에서 창출합니다. ( API의 비즈니스 가치 )

완성

API는 ESB와 웹 기반 포털을 대체하여 기업 간 통합의 주요 수단이 되었습니다. 디지털 경제에서 비즈니스 성공을 위한 전략적 구성 요소로서 API에 대한 의존성은 잘 입증되어 있습니다.

    o 60% 이상이 API 통합이 비즈니스 전략에 매우 중요하다고 동의했습니다. ( API 통합 현황 2018 )

    o 모든 B2B 협업의 50% 이상이 API 통합을 통해 이루어집니다. ( API 통합 현황 2018 )

    o 51%는 API 개발 결정을 내리는 데 있어 '외부 조직과의 파트너십'을 주요 동인으로 꼽았습니다.
        ( API 상태 2019 ) 

API에 대한 마이크로서비스와 같은 비즈니스 및 최신 애플리케이션 아키텍처의 의존성은 이러한 엔드포인트에 대한 액세스 또는 제어권을 얻는 것이 얼마나 중요한지 이해하는 공격자에게 특히 매력적인 대상이 됩니다. 이러한 위험은 API 계층에 더 많은 주의를 기울여야 한다는 것을 의미하며, 특히 API가 나타내는 비즈니스 기능에 대한 액세스 보안에 더 많은 주의를 기울여야 한다는 것을 의미합니다.

인증은 선택 사항이 아닙니다

API 보안은 액세스부터 시작됩니다. 즉, 인증을 의미합니다. 개방형 API는 API 접근 모델에 대한 설명이 되어서는 안 됩니다. 이는 API가 잘 문서화되어 있고 표준을 따른다는 것을 의미하는 속성입니다. API를 호출하려면 항상 인증이 필요하며, 이상적으로는 승인이 필요합니다.

다양한 옵션이 있으므로 선택하기 전에 각 옵션의 기능과 한계를 파악해야 합니다.

• 좋은: HTTP 기본
  기본값은 HTTP 기본 인증입니다. 이는 오늘날 대부분의 API와 같이 HTTP 기반 트래픽의 인증을 시행하는 가장 간단하고 일반적인 방법입니다. 기본 인증의 단점은 자격 증명이 필요하다는 점인데, 우리 모두 알고 있듯이 자격 증명은 종종 여러 애플리케이션에서 공유됩니다. 도난당한(또는 노출된) 자격 증명은 공격자가 시스템에 액세스하기 위해 사용하는 경로가 점점 더 많아지고 있습니다. 비밀번호의 강도와 비밀번호가 저장되는 위치/방법도 이 방법의 전반적인 보안에 영향을 미치는 요소입니다. 아무것도 하지 않는 것보다는 낫죠.
• 더 나은: API 키
  API 키는 발급자가 발급하고 추적되기 때문에 HTTP 기본 인증보다 한 단계 더 높습니다. API 키는 보안 이외에도 측정, 청구 등 다양한 목적으로 분배되어 사용됩니다. 하지만 이러한 쿠키는 일반적으로 정적이므로, 제3자가 합법적인 사용자인 것처럼 가장하기 위해 쿠키를 추출하여 사용할 가능성이 있습니다. 열쇠를 공유하는 것 역시 실제 문제입니다. 신원증과 마찬가지로 열쇠도 직장 동료나 가족이 공유할 수 있습니다. 그리고 이런 정보가 널리 퍼질수록 악의적인 의도를 가진 누군가가 이를 이용해 정보를 빼돌릴 가능성이 커집니다.
• 최상의: 만료되는 토큰
  API 수가 늘어나면서 토큰의 사용이 점점 더 일반화되었습니다. 오늘날 가장 인기 있는 두 가지 토큰은 OAuth 토큰(API에만 사용)과 JWT(JSON 웹 토큰)입니다. HTTP 기반 리소스에 대한 접근 권한을 요청하기 위한 표준 형식으로 JSON을 사용하고 API 외부에서도 적용 가능하기 때문에 JWT는 오늘날 가장 널리 사용되는 인증 및 권한 부여 메커니즘 중 하나가 되었습니다. RFC(7519) 도 있습니다. XML의 SAML과 마찬가지로, 인증된 사용자의 액세스 범위와 역할을 설명하는 JSON 어설션이 발행됩니다. 이 인증 방식은 휴대성이 뛰어나고, 중요한 점은 만료 날짜/시간이 있어서 인증된 사용자인 것처럼 가장하기 쉽지 않다는 것입니다. 단점은 토큰을 통합하는 데 더 많은 작업이 필요하고 항상 기본적으로 지원되지는 않는다는 것입니다. 이로 인해 구현 과정에서 실수가 발생하여 의도치 않게 악용 가능성이 생길 수 있습니다.

API 보안은 애플리케이션에 직접 구현할 수 있고, 더 나은 방법은 API 게이트웨이에 구현하는 것입니다. API 게이트웨이는 속도 제한(실수 또는 의도적인 서비스 거부 공격 방지) 및 권한 부여와 같은 기능을 통해 API를 추가로 보호할 수 있습니다 . 인증은 특정 API 호출에 대한 액세스를 지정된 클라이언트(일반적으로 토큰 또는 API 키로 식별)에게만 허용하여 API에 대한 액세스를 좁힙니다. API 게이트웨이는 사용되는 HTTP 메서드를 제한하고 다른 메서드를 남용하려는 시도를 기록하여 공격 시도를 파악할 수도 있습니다.

애플리케이션에 대한 의존성은 애플리케이션이 사용하는 API도 보호해야 한다는 것을 의미합니다. 아직 기본 사항부터 시작하지 않았다면, 지금이 시작해야 할 때입니다. 비즈니스를 보호하려면 안전한 API가 필요합니다.