PCI DSS v4.0 API 보안 컴플라이언스를 위한 모범 사례

원래 버전의 요구사항은 2006년 발표 당시와 마찬가지로 현재도 중요하게 여겨지는 보안 기본 요소들을 포함합니다. 예를 들면 다음과 같습니다.

• 카드 소유자 데이터를 처리하거나 저장하는 모든 IT 시스템의 모든 관리 계정에 대한 접속 모니터링 및 제어

• 알아야 할 사항에 따라 시스템 및 카드 소유자 데이터에 대한 접속 권한을 할당하고 역할별 접근 요구사항 정의

문제는 오늘날의 위협 환경이 2006년보다 더 복잡하다는 것입니다.

따라서 기업들은 공격자가 특권 계정과 과도한 권한을 가진 사용자를 표적으로 삼는 경향을 고려하여 대응해야 합니다. 그러나 오늘날의 기업들은 결제 기술에 내재된 수천 개의 API 를 빈번하게 목표로 삼는 공격자를 염두에 두고 컴플라이언스 프로그램을 조정하기도 해야 합니다. 공격자들은 API를 악용하기 쉽고 카드 소유자 데이터를 훔치는 효율적인 방법이 될 수 있다는 사실을 알고 있습니다.

그러므로 기업은 PCI DSS v4.0을 준수하기 위해 API 위협을 이해하고 방어해야 합니다. 이 블로그 게시물에서는 리스크, 요구사항 및 준수 방법에 관한 인사이트를 공유합니다.

전반적으로 PCI DSS v4.0은 다음과 같은 4가지 핵심 목표에 중점을 두고 있습니다.

1. 결제 업계의 보안 요구사항을 지속적으로 충족

2. 지속적인 프로세스로서 보안을 옹호

3. 기업이 요구사항을 충족하는 방식에 있어 유연성(새로운 툴, 새로운 제어 등) 제공

4. 검증 방법 및 프로세스 개선

PCI DSS v4.0은 API를 가시성과 보호가 필요한 핵심 영역으로 명시적으로 언급합니다. 4가지 목표 모두 여기에 적용됩니다. API의 고유한 리스크를 고려할 때, 세 번째 항목(새로운 툴과 제어를 활용할 수 있는 유연성)이 특히 중요합니다. 예를 들면 다음과 같습니다.

• API는 고객용 디지털 제품 및 서비스의 핵심에 있습니다. 평균적인 기업들은 규모에 따라 15000~25000개의 API를 보유하고 있으며, 모두 중단 없이 데이터를 교환하도록 설계되었습니다. 

• 이 데이터는 민감한 고객 정보를 포함합니다. 모든 디지털 결제에는 애플리케이션, 시스템, 써드파티 등 간에 데이터를 전송하는 API가 존재합니다.

• 감염된 API가 단 1개만 있어도 수백만 개의 기록이 도난당하거나, 랜섬을 치러야 하거나, 전 세계에 공개될 수 있습니다. 그리고 노출되거나 잘못 설정된 API는 널리 퍼져 있으며 쉽게 감염될 수 있고 보호, 조회, 관리가 되지 않는 경우도 많습니다.

규제 당국은 API에 대한 리스크를 인지하고 있으며, 기업은 데이터 감염을 방지하기 위한 가시성과 제어 기능을 갖추었음을 입증해야 합니다.

결제 카드 정보는 3분의 1(37%) 이상의 경우 데이터 유출로 인해 감염됩니다(출처: Verizon 2023 Data Breach Investigations Report). PCI DSS v4.0에는 결제 업계의 공격표면에 존재하는 인적 요소를 보호하기 위해 멀티팩터 인증 및 암호 길이에 대한 새로운 요구사항이 포함되어 있습니다.

그러나 데이터 유출 은 직원의 암호를 피싱 하는 것과 같이 널리 알려진 사람을 대상으로 한 공격에 의해 항상 발생하는 것은 아니라는 점을 기억하는 것이 중요합니다.

예를 들어, 이커머스 기업에 대한 공격의 18%는 카드 처리 웹페이지에 악성 코드가 삽입되어 발생합니다. 오늘날의 공격자들은 API처럼 IT 환경의 자동화된 비인간 구성요소를 표적으로 삼아 더 정교해지고 있습니다.

기업의  78%는 API 관련 보안 인시던트를 경험한 적이 있다고 합니다(출처: Akamai 리서치). API 위협의 긴급성을 인식한 듯 PCI DSS v4.0에는 새로운 API 보안 규칙, 지침 및 모범 사례가 포함되어 있습니다. 먼저 요구사항 6.2.3을 자세히 살펴봅시다.

요구사항 6.2.3은 기업이 맞춤형 사용자 지정 애플리케이션 코드(써드파티 벤더사가 개발한 애플리케이션이나, 상용 표준 애플리케이션 기성품을 의미하지는 않음)를 검토해 취약점이 프로덕션 환경에 노출되지 않게 해야 한다는 점을 강조합니다.

이 요구사항은 기업의 소프트웨어가 외부 구성요소의 기능(라이브러리, 프레임워크, API 등)을 안전하게 사용하는지 확인하기 위한 가이드를 제공합니다. 이는 API가 광범위한 소프트웨어 공급망에서 수행하는 핵심 역할을 시사하며, 이를 보호하는 데 필요한 것이 무엇인지도 나와 있습니다.

API는 최신 애플리케이션 환경에서의 기본적인 연결 및 데이터 교환 방법이 되었습니다. 이를 염두에 두고 프리프로덕션(시프트 레프트) 접근 방식과 포스트프로덕션(시프트 라이트) 접근 방식을 모두 이용해 API를 보호하는 것이 디지털 비즈니스에서 공격에 안정적으로 대응하는 데 있어서 필수입니다.

다음은 요구사항 6.2.3을 준수하는 데 도움이 되는 6가지 API 보안 모범 사례입니다.

1. API 기반 구성요소의 사용과 보안 체계 확인(예: 표준에 나와 있는 취약한 암호화 암호 사용을 포함해 취약점을 초래하는 설정 오류 탐지)

2. API 사용의 정상적이고 예상되는 행동을 검증하고 의심스러운 행위자가 시스템을 악용하는 것을 차단하기 위한 제어 구축(예: 애플리케이션의 행동을 확인해 논리적 취약점을 탐지)

3. API를 구동하는 데 사용되는 써드파티 프레임워크를 탐지해 오래되고 취약하지 않은지 확인

4. 실행 중인 API의 다양한 버전을 포함해 모든 API에 대한 전체 인벤토리를 구축해 잠재적으로 문서화되지 않은 기능 및 관리해야 하는 백도어에 대한 인사이트 획득

5. API 코드의 보안을 확인해 프로덕션 환경에 배포하기 전에 API와 관련된 취약점을 찾아내고 방지

6. API에 관한 보안 코딩 모범 사례를 구현해 프로그래밍 접근 방식으로 코드를 지속적으로 안전하게 전달

PCI SSC는 또한 API 보안을 구성하는 2개의 다른 섹션을 PCI DSS v4.0에 추가했습니다. 다음은 기업이 충족해야 할 2가지 추가 요구사항을 요약한 내용입니다.

• 요구사항 6.3.2 는 취약점 및 패치 관리를 용이하게 하기 위해 맞춤형 사용자 지정 소프트웨어 그리고 맞춤형 사용자 지정 소프트웨어에 통합된 써드파티 소프트웨어 구성요소의 인벤토리를 유지 관리하는 데 적용됩니다.

• 요구사항 6.2.2 는 맞춤형 사용자 지정 소프트웨어 관련 업무를 하는 소프트웨어 개발 인재들을 대상으로 하는 교육을 다룹니다. 여기서는 개발자가 보안 소프트웨어 설계 및 보안 코딩 기술을 포함해 자신의 직무 기능과 관련된 보안에 대해 최소 12개월에 한 번씩 교육을 받아야 한다고 설명합니다. 이 교육은 보안 테스트 툴과 이러한 툴을 사용해 소프트웨어의 취약점을 탐지하는 방법을 포함합니다.