API 보안을 컴플라이언스에 포함하기: 주목해야 할 여섯 가지 사례
Q: API 보안 인시던트로 인해 기업에 벌금이 부과되는 이유는 무엇인가요?
A: 공격자들은 이미 알고 있는 것을 규제 당국이 이제 파악하기 시작했기 때문입니다. 그것은 바로 노출되거나 잘못 설정된 API가 널리 퍼져 있고, 쉽게 감염될 수 있으며, 보호되지 않는 경우가 많다는 사실입니다.
취약한 API가 하나만 있어도 충분
고객, 파트너 또는 벤더사가 디지털 방식으로 비즈니스와 소통할 때마다 그 이면에 있는 API 를 통해 데이터(종종 민감한 데이터)를 신속하게 교환되곤 합니다. 오늘날의 공격자들은 데이터를 훔치기 위해 항상 복잡하게 여러 단계를 거쳐야 할 필요는 없다는 것을 알고 있습니다. 대신 공격자들은 애플리케이션과 같은 중간 단계를 우회해 직접 API를 공격할 수 있습니다.
200페이지 분량의 규정 문서에 API 보안 이 중요하다고 명시적으로 언급하거나, 미묘하게 암시하거나, 모호하게 표시하는 것이 중요할까요? 그렇지 않습니다. 데이터 유출은 실행 방법이나 장소와 상관없이 데이터 유출이기 때문입니다. 취약한 API가 하나만 있어도 데이터가 감염되거나, 도난당하거나, 전 세계가 볼 수 있도록 공개될 수 있습니다.
기다리는 동안 발생하는 데이터 유출
랜섬웨어와 같이 규제 기관이 주목하고 있는 위협에 우선순위를 두는 동안 API 보안이 기다려줄까요? 안타깝게도 아닙니다. API는 기업이 새로운 디지털 제품과 서비스를 출시함에 따라 그 수와 리스크가 증가합니다.
설문 조사에 참여한 기업의 76%가 API 보안 인시던트를 경험했으며, 대부분 보안 인시던트를 막을 수 있는 제어나 툴을 갖추지 못한 것으로 나타났습니다. 한편 데이터 유출로 인한 평균 비용은 규정을 준수하지 않는 기업의 경우 12.6%(505만 달러)까지 증가합니다.
선제적 접근 방식을 취해 모든 API를 찾아내고, 각각의 리스크를 평가하고, 유출로부터 보호한다면 규제 당국이 방지하고자 하는 정확한 결과로부터 데이터를 보호할 수 있습니다.”
컴플라이언스 프로그램에 미치는 영향
선제적 접근 방식을 취해 모든 API를 찾아내고, 각각의 리스크를 평가하고, 유출로부터 보호한다면 규제 당국이 방지하고자 하는 정확한 결과로부터 데이터를 보호할 수 있습니다.
이 블로그 게시물에서는 API 보안의 필요성을 나타내는 여섯 가지 규정 및 가이드라인에 대한 개괄적인 검토와 함께 이를 준수하기 위한 방법의 주요 예시를 소개합니다.
여섯 가지 주요 규정 및 프레임워크
1. PCI DSS(Payment Card Industry Data Security Standard) 버전 4.0
PCI DSS 는 결제 데이터 보안을 위한 글로벌 표준으로 자리 잡았습니다. 주요 신용 카드를 수락하고 카드 소유자의 데이터를 전자적으로 처리, 저장 또는 전송하는 기업은 규정을 준수해야 합니다.
PCI DSS 4.0 요구사항 6.2.3은 기업이 맞춤형 사용자 지정 애플리케이션 코드를 검토해 취약점이 프로덕션 환경에 노출되지 않도록 해야 한다는 점을 강조합니다. API와 관련된 이 요구사항은 기업의 소프트웨어가 외부 구성요소의 기능(라이브러리, 프레임워크, API 등)을 안전하게 사용하는지 확인하기 위한 가이드를 제공합니다.
여러 가지 준수 방법 중 하나는 API 사용의 정상적이고 예상되는 행동을 검증하고 의심스러운 행위자가 시스템을 악용하는 것을 차단하기 위한 제어를 구축(예: 애플리케이션의 행동을 확인해 논리적 취약점을 탐지)하는 것입니다.
2. GDPR(General Data Protection Regulation)
GDPR 은 유럽 연합 내 개인에 대한 데이터 보안을 강화하고 통합하는 것을 목표로 하는 유럽 연합 법률 규정입니다. 그러나 GDPR은 유럽 연합에 기반을 둔 기업에 국한되지 않으며, 유럽 연합에서 소비재나 서비스를 제공하는 모든 기업이 준수해야 합니다.
GDPR 제25조는 최소 권한에 뿌리를 두고 있으며, 기업은 ‘기본적으로 각 특정 목적에 필요한 개인정보만 처리하도록 보장하기 위한 기술 및 기업적 조치’를 구축해야 합니다. 이에 따라 API 개발자는 사용자 인증 및 권한 제어를 구축해 API를 통해 흐르는 민감한 데이터를 보호해야 합니다.
이는 API 보안이 기업의 전반적인 보안 및 컴플라이언스 프로그램에 어떻게 부합하는지 보여주는 좋은 예시입니다. 최소 권한과 같은 개념은 인간에게만 적용되는 것이 아니며, API도 업무를 수행하기 위한 적절한 수준의 접속 권한을 가져야 합니다.
3. DORA(Digital Operational Resiliency Act)
유럽 연합의 총 2만 2000곳 이상의 금융 기관과 IT 서비스 공급업체가 사이버 공격을 견디고 복구하는 데 도움을 주기 위한 DORA의 요구사항에 영향을 받습니다.
API 보안은 DORA에 어떻게 적용될까요? 기업이 ICT 솔루션과 프로세스를 사용하도록 요구하는 DORA 제3조의 내용을 살펴봅시다.
데이터 관련 리스크, 무단 접속, 기술적 취약점 최소화
데이터 불용성, 데이터 손실, 무결성 및 기밀성 유출 방지
데이터 전송 보안 보장
API의 주요 목적이 데이터 전송이라는 점을 고려할 때, 인증 제어 부족 및 의도치 않은 퍼블릭 인터넷 노출과 같은 취약점을 정기적으로 테스트하는 것이 필수입니다. API 테스트에 시프트 레프트(shift-left) 접근 방식을 적용하면 취약점이 프로덕션 환경에 도달하는 것을 막을 수 있습니다.
4. HIPAA(Health Insurance and Portability and Accountability Act)
HIPAA 는 전자 건강 기록 및 헬스케어 IT 시스템에서 PHI(Protected Health Information)를 보호하기 위한 데이터 개인정보 보호 및 보안 규정에 중점을 둡니다. PHI를 전자적으로 저장하거나 전송하는 모든 미국 헬스케어 공급업체, 보험 관리자 또는 정보 센터는 HIPAA를 준수해야 합니다.
HIPAA의 개인정보 보호 규정에는 적용 대상 기관이 ‘직원들의 특정 역할에 따라 보호 대상 건강 정보의 접속 및 사용을 제한하는 정책과 절차를 개발하고 구축해야 한다’고 명시되어 있습니다.
따라서 기업의 API 개발자는 인증, 고유 사용자 ID, 역할 기반 접속 제어와 같은 기술적 보호 장치를 포함시켜 최소 권한을 보장해야 합니다.
5. NIS2(Network and Information Security Directive)
유럽 연합은 2023년 1월에 IT 인프라 보안 및 인시던트 보고에 대한 기존 버전의 지침을 기반으로 한 NIS 지침 버전 2.0을 도입했습니다.
주목할 만한 점은 NIS2 에 공급망 보안에 대한 새로운 강조점 즉, 이제 기업은 리스크를 평가하고 IT 공급망과 써드파티 공급업체 관계를 보호해야 한다는 점이 포함되어 있다는 것입니다.
API는 소프트웨어 벤더사부터 클라우드 서비스 사업자에 이르기까지 외부 서비스를 통합하는 데 자주 사용되므로, API 보안을 보장하는 것은 규제 기관에 기업이 고객의 데이터와 광범위한 공급망을 공격으로부터 보호하고 있음을 보여주는 데 핵심적인 역할을 합니다.
6. FFIEC(Federal Financial Institutions Examination Council)
FFIEC는 연방 규제 당국이 미국 금융 업계를 감독하기 위한 가이드와 표준을 만듭니다. 여기에는 연방준비제도와 FDIC가 포함됩니다. 이 위원회의 임무는 사기, 남용, 위법 행위로부터 소비자와 투자자를 보호하는 것입니다.
FFIEC의 가이드라인을 검토해 보면 사기 및 신원 도용으로부터 기업이 소비자를 보호하는 데 API 보안이 도움이 되는 방법 을 명확히 알 수 있습니다. 예를 들어, FFIEC는 기업이 인증 및 접속 제어가 필요한 모든 정보 시스템(API 포함)의 인벤토리를 구축할 것을 권장합니다.
권한 부여도 중요한데 예를 들어, FFIEC는 무단 API 접속을 식별하고 추적하기 위해 활동을 모니터링하고, 기록하고, 보고하는 등 레이어드 보안을 구축할 것을 권장합니다.
신뢰 확보의 의미이기도 한 API 보안
이 블로그 게시물에서 논의한 여섯 가지 규정과 가이드라인은 다른 사람이 맡긴 데이터를 보호한다는 한 가지 공통점이 있습니다.
아시다시피 API 데이터 유출 의 리스크는 단순한 벌금 이상의 의미를 갖습니다. 고객, 직원, 해당 업계를 관할하는 규제 당국 사이에서 신뢰와 평판이 위태로워지는 것입니다. 규제 당국은 이와 같은 공격이 발생하지 않도록 적절한 인력, 프로세스, 툴을 적절히 조합해 적용하고 있는지 확인해야 합니다.
자세히 보기
이 게시물에서 논의한 여섯 가지 규정에 대한 API 관련 요구사항을 더 자세히 알고 싶나요?