헬스케어 생태계에서 결제업체가 API 보안의 중추적인 역할을 하는 이유
Akamai는 SOTI(State of the Internet) 보고서발행 10주년을 맞아 헬스케어 및 생명과학을 비롯한 주요 업계에서 얻은 인사이트를 공유합니다. 이번 블로그 게시물은 올해 말 종합 보고서로 마무리될 SOTI 시리즈의 첫 번째 블로그 게시물입니다.
임상 및 재무 데이터에 대한 강력한 접속 권한을 가진 결제업체는 헬스케어 생태계 전반에서 데이터 공유의 중심이며, 이러한 공유 과정에서 API(Application Programming Interface)에 대한 의존도가 점점 더 높아지고 있습니다. API는 공급업체, 결제업체, 환자, 그리고 전자 건강 기록 시스템, 의료 기기 회사, 건강 정보 교환과 같은 기타 써드파티 간에 데이터를 공유할 수 있게 해줍니다.
상호 운용성을 추구하면 환자 치료 및 재정적 성과를 개선할 수 있지만 주요 컴플라이언스 요구사항, 보안 고려사항과 같이 상충되는 측면도 있습니다. 사이버 범죄자와 애그리게이터는 이러한 기능을 공격하고 악용하며, 이로 인해 안전 및 개인정보 보호 문제가 발생할 수 있습니다.
결제업체의 경우 API를 이용한 공격은 공개 등록 및 청구 운영에 영향을 미치는 서비스 중단을 초래하고, 비용 부담이 큰 다운타임으로 이어지며, 브랜드 평판이 손상될 수 있습니다.
이 블로그 게시물에서는 API 공격과 관련된 위협 데이터 및 트렌드를 분석해 리스크의 정도를 파악하고 이를 방어하기 위한 모범 사례를 제시합니다.
현미경으로 들여다보는 API 공격
Akamai 리서치에 따르면 2023년 1월부터 12월까지 헬스케어 생태계(결제업체, 공급업체, 제약 및 생명과학 기업)를 표적으로 삼은 API 공격 중 약 절반이 결제업체를 겨냥한 것으로 나타났습니다. 이는 디지털 중심화가 덜한 다른 하위 업계에 비해 결제업체가 공격자의 API 남용 리스크에 더 집중적으로 노출되어 있음을 보여줍니다.
다른 규제 대상 업계, 특히 결제 시스템을 다루는 업계에서도 비슷한 트렌드를 보입니다. 예를 들어 금융 업계는 디지털 혁신의 여정에서 한발 더 나아가, 이미 비즈니스 모델의 일부로 더 많은 통합 API를 사용하고 있습니다. 오픈 뱅킹은 API 사용을 촉진하는 동시에 더 많은 보안 리스크를 초래하고 있습니다. 따라서 금융 부문에서는 API를 겨냥한 공격이 더욱 집중적으로 발생하고 있습니다. (공격 트렌드에 대한 자세한 내용은 Akamai의 최신 인터넷 현황 보고서 숨어 있는 API 위협에 대한 API 위협을 보여주는 공격 트렌드에서 확인할 수 있습니다.)
Akamai 연구원들은 결제업체 API 공격 데이터를 면밀히 분석해 1년간의 활동 변화, 특히 분기별 활동 변화를 관찰했습니다. 이는 예상 데이터와 실제 데이터를 조정하기 위한 분기말 시스템 간의 동기화를 반영할 수 있습니다.
하지만 2023년 4분기 초 Akamai 연구원들이 관측한 활동 급증 현상과 해당 기간 동안의 전반적인 활동 증가는 공격자들이 공개 등록 기간을 노리고 운영을 방해하기 때문일 가능성이 높습니다(그림).
2023년 API에 대한 웹 공격은 매 분기마다 증가하는 트렌드를 보였으며, 마지막 분기에는 전반적으로 증가했습니다.
점점 더 많은 API를 요하는 규제 환경
데이터 교환을 통해 더 나은 재무 및 임상 결과를 얻을 수 있다는 약속과 이러한 교환을 의무화하는 규제 요구사항을 준수해야 한다는 요구는 서로 밀접한 연관이 있습니다. 따라서 이 2가지 측면을 모두 이해하고 모두 최적화하는 것이 중요합니다.
진료 횟수보다 건강 결과에 따라 보상하는 종단적 접근 방식인 VBC(Value-Based Care )로의 전환은 현재 공유해야 하는 정보의 양과 다양성을 보여주는 대표적인 예입니다. 결제업체는 오랫동안 환자 및 공급업체의 금융 데이터에 접속할 수 있었습니다. 그러나 복약 준수 및 병원 입원과 같은 더 많은 VBC 데이터 포인트에는 보다 혁신적이고 상호 운용 가능한 연속성이 필요하며, 이러한 데이터를 공유할 수단이 필요합니다. 그 통로 역할을 하는 것이 바로 API입니다.
현재 API 사용이나 보안을 구체적으로 다루는 규정은 없지만GDPR(General Data Protection Regulation), 유럽연합의 개정된 PSD2(Payment Services Directive),PCI DSS(Payment Card Industry Data Security Standard) 등 API 요구사항이 포함된 여러 기존 규정이 있습니다.
API에 대한 요구사항은 빠르게 진화하고 있습니다. 특히 2024년 3월에 발표될 PCI DSS v4.0에는 시스템과 소프트웨어의 개발 및 유지 관리의 감염 리스크 감소를 위한 API 사용에 관한 새로운 표준이 포함되어 있습니다.
결제업체 역시 새로운 CMS 상호운용성 및 사전 승인 룰 에 따라 3가지 주요 범주의 API를 유지 관리해야 합니다.
환자 접속 API: 이를 통해 회원의 의료 데이터에 대한 접속이 증가하고 회원 만족도가 높아질 수 있습니다.
공급업체 디렉토리 API: 회원이 자신의 위치와 전문 분야를 기준으로 헬스케어 공급업체 및 시설을 검색할 수 있도록 함으로써 헬스케어 서비스에 대한 접속을 개선합니다.
결제업체-공급업체 및 결제업체-공급업체 API: 이를 통해 환자 치료의 공백을 해결하고 줄일 수 있으며 중복되고 비용이 많이 드는 서비스도 줄일 수 있습니다.
더 큰 목적은 고비용 관리 부담, 특히 환자가 특정 의료 절차를 수행하기 전에 보험 회사의 승인을 기다려야 하는 사전 승인의 수동 처리에 대한 부담을 경감하는 것입니다. 지연이 발생할 경우 의료 서비스에 부정적인(그리고 종종 과다한 비용이 발생하는) 영향을 미칠 수 있습니다.
미국 헬스케어 업계는 사전 승인 절차를 포함한 행정적 복잡성으로 인해 연간 2656억 달러의 비용을 지출하고 있습니다."
더 나은 성능은 더 큰 리스크를 초래할 수 있습니다
환자들이 모든 애플리케이션에서 동일한 수준의 사용자 경험을 기대함에 따라 성능은 더 큰 관심사가 되고 있습니다. 이는 서비스 거부 공격과 악용 공격으로부터 헬스케어 생태계를 보호해야 한다는 것을 의미합니다.
결제업체의 높은 API 사용률은 엄청난 장점을 제공하지만, 동시에 리스크를 초래하기도 합니다. API가 확산되면 공격표면이 확장되면서 가시성이 부족해져 문제가 더욱 악화될 수 있습니다. API는 복잡한 디지털 혁신 프로젝트의 일부인 경우가 많기 때문에 헬스케어 기업의 보안 프로그램에는 더더욱 잘 드러나지 않을 수 있습니다. (하지만 OWASP 상위 10대 API 보안 리스크와 같은 훌륭한 참조 표준이 있습니다.)
일상적인 비즈니스 활동과 관련된 의료 및 금융 데이터는 모두 규제가 엄격하고 사이버 범죄자의 표적이 될 가능성이 높기 때문에 결제업체의 과제가 더욱 복잡해집니다.
가시성을 통한 생태계 보호
API 보안 은 아제 리스크 관리 및 컴플라이언스 관점에서 그 어느 때보다 중요합니다. 그러나 API의 확산으로 인해 헬스케어 API를 식별, 분류, 방어하는 일은 점점 더 복잡해지고 있습니다.
4가지 전략 이정표
강력한 API 보안 프로그램을 도입하면 모든 API에 대한 가시성 을 개선하고 리스크 노출도를 파악해 보호 수준을 높일 수 있습니다. 다음은 강력한 API 보안 프로그램을 위한 4가지 전략 이정표입니다.
악성 또는 섀도 API를 체계적으로 발견해 인프라 사각지대를 제거하고, 각 API가 폐기되거나 API 보안 제어에 통합되도록 합니다.
일반적인 알림의 종류를 분석하고 API 코드의 결함을 수정하고, 잘못된 설정 문제를 해결하고, 교훈을 바탕으로 향후 취약점을 방지하기 위한 프로세스를 구축해 리스크 체계를 결정하고 강화합니다.
정상적인 행동을 이해하고 API 보안 알림의 급증을 기반으로 잠재적인 악용을 식별해 위협 탐지 및 대응을 강화합니다. 그런 다음 잘 정의된 대응 절차에 따라 리스크 및 알림 규모를 정상 수준으로 낮춥니다.
- 대응 시나리오로 확대되기 전에 가능한 위협을 탐지하는 것을 목표로 공식적인 API 위협 탐색 규율을 확립해 더욱 강력한 방어 체계를 개발합니다.
지금이 바로 행동해야 할 때
혁신은 멈추지 않을 것이며 지금이 바로 API를 제어해야 할 때입니다. 탄력적인 헬스케어 기업은 상황 인식을 제공하고, 조사를 용이하게 하며, 신속한 대응을 실행할 수 있는 기능이 필요합니다.
자세히 보기