지속적인 API 보안을 위한 방법 (2)

API의 지속적인 보안을 위한 5단계

 

 

1. 지속적인 보안 문화를 조성

API 보안을 이해하고 관리하는 것은 쉬운 일이 아닙니다. 조직의 리더는 조직 전체, 특히 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 보안 문화를 육성해야 합니다. 이를 통해 가시성, 거버넌스 및 협업 능력이 향상될 수 있습니다.

 

다음은 조직에서 지속적인 보안 문화를 조성하고 유지하기 위해 사용할 수 있는 몇 가지 실용적인 팁입니다.

 

보안팀의 분산 배치

 

개발 조직 및 제품 라인에 보안 전문가를 포함시켜 가시성과 거버넌스를 개선해야 합니다. 이렇게 하면 자체적으로 팀 상황에 의존하는 것보다 더 유연하게 정책을 생성할 수 있습니다.

 

보안팀이 모든 디지털 정책 설정에 참여하도록 보장

 

단순히 정책 수립을 위해서가 아니라 각 서비스를 출시할 때부터 적극적으로 보안팀의 적극적인 개입을 추진해야 합니다. LOB(Line of Business) 소유자, 해당 팀 및 개발자는 보안 담당자와 열린 커뮤니케이션 라인을 갖추어야 합니다.

 

보안 담당자 지정

 

사업부 내에서 전담자를 지정하면 신속한 작업을 위한 핵심적인 관계를 구축하고 유지하는 데 도움이 됩니다. 전담 보안 담당자를 통해 보안 메시지를 지속적으로 강화하고 부서 간의 서로 책임을 지도록 권한을 부여할 수 있습니다.

 

보안 교육

 

보안 교육은 필수입니다. 그리고 개발자와 엔지니어뿐만 아니라 본질적으로 소프트웨어 개발 프로세스 및 그 이상 관련된 모든 사람을 대상으로 진행해야 합니다.

 

 

 

2. API 보안 태세 평가

대다수의 조직은 API 자산의 규모를 과소평가합니다. 조직들은 종종 보유하고 있는 API의 수가 애플리케이션의 수와 같다고 생각합니다. 실제로 애플리케이션에는 원래 예상하는 것보다 10배 이상의 API가 포함되어 있습니다. 정확한 API의 인벤토리를 생성할 수 있다면 공격 노출 영역을 평가할 수 있는 정확한 청사진을 얻을 수 있습니다.

 

다음 권장 사항을 통해 API 보안 상태를 완벽하게 파악할 수 있습니다.

 

전체 인벤토리 생성

 

잠재적인 공격 노출 영역에 대한 명확하고 정확한 그림과 API 및 웹 애플리케이션 전반에 걸쳐 실제 상황을 파악할 수 있습니다. 레거시 및 섀도 API를 포함하여 모든 API를 포괄적으로 검색하여 인벤토리를 생성하는 API 검색 도구를 사용해야 합니다.

 

각 API 및 소유자 식별

 

주고받는 민감한 데이터의 유형, 라우팅 방법, 관련된 물리적 리소스 및 해당 데이터가 속한 비즈니스 단위 또는 애플리케이션을 식별해야 합니다.

 

보안팀 리소스 할당 검사

각 팀원이 관리해야 하는 API의 수를 파악해야 합니다. 더 많은 기술 또는 훈련이 보안 태세를 유지하거나 개선할 수 있는지를 결정해야 합니다.

 

 

 

3. 교정, 자동화 및 통합

기업은 API 액세스, 사용 및 동작 모두를 이해해야 합니다. 그러나 API는 분석하기가 매우 복잡합니다. 이렇듯 복잡한 API 보안 환경을 이해하기 위해서는 로그 구문 분석, 카탈로그 데이터 수집, API 구성 검토, 보안 테스트 및 장치 구성 평가와 같은 프로세스가 필요합니다. 적절한 분석 도구가 없으면 교정 작업이 기술적으로 어려울 수 있으며, 상당한 시간과 노력이 필요합니다. 그러나 교정 작업이 제대로 진행되면 프로세스는 자동화 또는 반자동화할 수 있으며, 그 이후에는 사람의 개입이 거의 필요하지 않습니다. 궁극적으로 알려진 취약점을 제거하고 즉각적인 위험을 완화할 수 있습니다.

 

다음은 공격을 방지하고 잘못된 구성을 해결하는 데 도움이 되는 몇 가지 지침입니다.

 

기존의 IT 워크플로 관리 시스템과 통합

 

문제가 식별되면 적절한 팀에 문제를 할당해야 합니다. 관련 시스템과의 통합을 통해 조직 내 API 문제를 해결하기 위한 자동화 워크플로를 실행해야 합니다.

 

단계적으로 자동화된 업데이트 적용

 

초기에는 새로운 교정 작업을 취하기 전에 사람이 승인해야 합니다. 또한 반자동 교정 작업을 수행하기 위해 관련 사업부와의 조정이 필요합니다. 단순히 개발자에게 소스 코드가 위험하다고 말하는 것만으로는 충분하지 않을 수 있습니다. 개발자가 실질적으로 사용할 수 있는 실행 가능한 가이드가 필요합니다. 그렇지 않으면 개발자의 시간을 낭비하게 됩니다. 같은 문제가 계속 재발한다면 완전 자동화를 활용하여 문제 해결을 가속화할 수 있도록 해야 합니다.

 

악성 행위 모니터링

 

API 공격 전술에 대한 과거 지식을 활용하여 공격자의 의도를 드러낼 수 있는 비정상적인 동작을 확인합니다. 자동화 또는 반자동 대응 방법을 활용하여 공격을 완화해야 합니다.

 

기존 SIEM 시스템과 통합

 

대규모의 팀이 API 보안 데이터를 활용할 수 있도록 지원해야 합니다.

 

 

 

4. API 보안의 원점 회귀

API 개발의 경우 테스트를 할 때도 문제가 발생합니다. 기존 모델의 경우 테스트는 배포 단계의 바로 이전에 배치됩니다. 테스트는 매우 중요한 단계이지만 배포 직전에 테스트를 하기에는 시간이 충분하지 않을 수 있으며, 이는 곧 심각한 상황으로 이어질 수 있습니다. Shift-Left는 개발 프로세스에서 다양한 작업을 가능한 한 초기 시점으로 이동하는 접근 방식입니다. API 개발의 각 단계에 보안 및 테스트를 포함시키는 접근 방식을 통해 개발자는 개발 라이프사이클 전반에 걸쳐 취약성을 모니터링할 수 있습니다. 이를 통해 조직은 혁신을 가속화하고 경쟁 우위를 강화할 수 있습니다.

 

다음은 Shift-Left API 테스트를 채택하는 데 도움이 되는 몇 가지 제안입니다.

 

목표 정의

 

Shift-Left는 조직 및 문화적인 변화가 필요하기 때문에 경영진은 우선 개발 라이프사이클에 도입된 새로운 도구나 프로세스가 팀의 기존 개발 및 테스트 방법론에 적용되도록 프로세스의 목표를 정의해야 합니다.

 

공급망 이해

 

포괄적인 Shift-Left 보안 프로그램을 설계하기 전, 조직은 앱과 소프트웨어를 개발하는 방법과 위치를 파악해야 합니다. 공급망의 보안 위험 태세는 주로 공급망 내의 보안 숙련도에 따라 달라집니다. 또한 개발자가 라이프사이클 초기에 테스트를 수행할 수 있는 단계를 식별할 수 있도록 돕습니다.

 

보안 자동화 도구를 사용한 보안 프로세스 자동화

 

개발팀이 마이크로 서비스를 출시할 때 임베디드 보안 전문가가 처음부터 API 보안 도구를 사용하여, 컨테이너화로 인해 발생할 수 있는 위험을 모니터링할 수 있도록 해야 합니다.

 

일관된 도구 사용

 

보안팀이 개발팀의 기본 인터페이스를 채택하고 개발자가 선호하는 도구, 워크벤치 및 언어에 적응하도록 장려해야 합니다. 예를 들어, 취약점 또는 기타 사항들은 일반적인 사용자 사례와 마찬가지로 새로운 애플리케이션 기능 요구 사항에 대해 동일한 제품 백로그에 입력할 수 있습니다.

 

앱 보안팀을 혁신의 원천으로 만들기

 

지속적 제공 원칙을 활용하여 위험을 완화하는 보안 별 마이크로 서비스를 개발하여 조직에서 동료가 할 수 없는 작업을 수행할 수 있도록 해야 합니다.

 

 

 

5. 지속적인 테스트

위와 같은 Shift-Left 보안 접근 방식은 테스트를 타임라인의 왼쪽으로 이동시키기 때문에 개발 라이프사이클 내에서 더 빠르게 더 자주 테스트를 수행하게 됩니다. 이에 반해 테스트를 오른쪽으로 이동시키는 Shift-Right 접근 방식은 개발 환경에서는 구현하기 불가능한 실제 사용자 및 시나리오를 대상으로 테스트를 실시할 수 있습니다. Shift-right 테스트는 프로덕션 환경에서 테스트하여 실제 소프트웨어 안정성과 성능을 보장하고, 애플리케이션 사용자로부터 피드백과 리뷰를 수집하여 사용자 경험을 개선합니다. 결론적으로 둘 중 어느 쪽도 완벽한 접근 방식은 아니라는 것입니다. 명확한 것은 잠재적인 위험을 최소화하기 위해 조직은 지속적으로 테스트를 해야 합니다.

 

다음은 조직이 지속적인 보안 문화를 개발하고 유지하는 데 사용할 수 있는 방법입니다.

 

적극적인 API 테스팅 수행

 

API 소프트웨어 개발 라이프사이클의 일부로써 API 보안 테스트를 실행하여, 프로덕션 전후에 발생할 수 있는 잠재적인 문제를 해결해야 합니다. 또한 배포 전후 각 API의 무결성을 검증해야 합니다.

 

지속적인 API 트래픽 모니터링

 

API의 사용량을 추적하고 API 트래픽 메타데이터를 분석해야 합니다. 실시간 트래픽 분석은 기존의 API와 새로운 API의 변경 사항을 파악합니다. 분석 프로세스는 자동화되어 반복 및 실행이 가능해야 합니다. 악용되기 전에 문제를 식별하여 해결할 수 있어야 합니다. 분석이 지연되면 공격자가 취약성을 이용할 수 있는 추가 시간이 주어질 수 있습니다.

 

취약점 및 잘못된 구성 모니터링

 

테스트는 개발과 병행하여 지속적으로 실행되어야 하며 클라이언트, 개발자 및 테스터 간의 지속적인 커뮤니케이션이 포함되어야 합니다. 또한 정책 또는 기능의 변경 사항을 보고하고 SIEM 시스템을 업데이트해야 합니다.

 

API 트래픽 기록

 

특정 API 키, 토큰, IP 주소 및 사용자 ID에 대한 포렌식 보고서를 생성해야 하는 경우 API 트래픽을 기록해야 합니다.

 

 

 

API 보안은 새로운 사고방식, 다양한 프로세스, 팀 간 협업이 필요하지만 해결할 수 있는 과제입니다. 보안 전문가에게 큰 어려움을 가져올 수 있으나, 올바른 접근 방식으로 헤쳐 나갈 수 있습니다. API 보안에 대해 더 많은 정보가 필요하시다면, Noname Security와 함께하는 eNsecure와 상의하세요 :D

 

 

 

 

출처: Noname Security, continuous-security-apis-whitepaper