Build intelligent security for healthcare APIs with Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

기존 FHIR 인증·권한 통제를 유지하면서 비동기 Amazon Bedrock 분석으로 이상 접근 탐지, 데이터 민감도 분류, 규정 준수 보고를 보강하고 임상 API 지연과 PHI 노출 위험을 줄이는 보안 설계다.

📌 핵심 요약

• FHIR API는 환자 데이터 접근성과 엄격한 보호 요건을 함께 충족해야 하지만, 임상 업무 흐름이 변할 때마다 정적 보안 규칙을 수동으로 갱신하면 규정 준수 공백이 생길 수 있다.
• 제시된 아키텍처는 기존 RBAC와 JWT 검증을 유지한 채 접근 이벤트를 Amazon EventBridge로 전달해 이상 탐지, 민감도 분류, 규정 준수 보고를 비동기로 수행한다.
• 이상 분석기는 사용자의 역할, 과거 접근 행동, 요청 성격, 데이터 민감도와 인증 패턴을 함께 평가해 권한 범위 안에서 발생하는 비정상적인 시간대나 대량 접근도 식별한다.
• Amazon Bedrock Guardrails, Amazon Comprehend Medical, IP 일반화, PHI 없는 알림, 구조화된 출력, 일반화된 오류 메시지를 조합해 모니터링 과정의 환자정보 노출을 제한한다.
• FHIR 리소스의 유형, 임상 코드, 범주를 바탕으로 PUBLIC·INTERNAL·CONFIDENTIAL·RESTRICTED 중 하나를 지정하므로 하드코딩된 매핑 표 없이도 새로운 코드와 리소스 범주에 대응할 수 있다.

🧩 주요 포인트

1. FHIR 응답 경로와 보안 분석 경로를 분리한다 → 분석 장애나 처리 시간이 임상 요청의 응답 지연과 가용성 문제로 이어지지 않는다.
2. 전체 사용자에게 동일한 임계값을 적용하지 않고 사용자·역할·애플리케이션별 행동 기준선을 활용한다 → 정상적인 야간 근무나 연구 목적의 대량 접근을 일률적으로 오탐하는 위험을 줄이면서 비정상 패턴을 포착한다.
3. 모델 입력부터 로그와 알림까지 여러 단계에서 PHI를 비식별화하고 출력 형식을 제한한다 → 자연어 기반 분석을 활용하면서도 감사 데이터와 후속 처리의 예측 가능성을 높인다.

🧠 상세 정리

1. FHIR API 보안의 문제와 해결 범위

FHIR API 운영자는 환자 데이터의 개방적 활용을 지원하는 동시에 엄격한 개인정보 보호와 규정 준수 요건을 지켜야 한다. 그러나 임상 업무 흐름과 사용자 행동이 계속 변하면 역할, 시간대, 접근량 등을 기준으로 작성한 정적 규칙도 지속적으로 수정해야 하며, 수동 유지 과정에서 규정 준수 공백이 발생할 수 있다. 이 글은 Amazon Bedrock의 기반 모델을 이용해 접근 패턴을 감시하고, 데이터 민감도를 자동으로 분류하며, 규정 준수 보고서를 자연어로 생성하는 방법을 제시한다. 목표는 기존 인증과 권한 통제를 대체하는 것이 아니라, 정적 규칙만으로 발견하기 어려운 행동상의 이상을 별도 보안 계층에서 분석하는 것이다. 함께 제공되는 예제에는 전체 AWS CloudFormation 템플릿, 다섯 개의 AWS Lambda 함수, 환경에 맞게 수정할 수 있는 배포 스크립트가 포함된다.

2. 배포 전제조건과 운영 준비

솔루션을 배포하려면 관리자 권한이 있는 활성 AWS 계정과 설치·설정이 완료된 AWS CLI 버전 2가 필요하다. Amazon Bedrock은 지원 모델 접근 권한을 자동으로 제공하지만, 실제로 사용할 모델이 배포 대상 AWS 리전에서 제공되는지는 모델 접근 페이지에서 확인해야 한다. 보안 경보를 Amazon SNS로 받으려면 검증된 이메일 주소도 준비해야 한다. 해당 계정에서 Amazon API Gateway와 Amazon CloudWatch Logs 연동을 사용한 적이 없다면 API Gateway 계정 설정에 CloudWatch Logs 역할 ARN을 먼저 지정해야 하며, 그렇지 않으면 관련 역할 ARN이 설정되지 않았다는 오류와 함께 배포가 실패한다. 예상 배포 시간은 10~15분이고 월 비용은 사용량에 따라 달라지며, AWS HealthLake 비용은 별도로 부과된다.

3. 기존 권한 통제를 유지하는 비동기 아키텍처

Amazon API Gateway는 들어오는 FHIR 요청에 대해 요청 검증과 속도 제한을 수행하고, AWS Lambda 권한 부여자는 JWT를 검증한 뒤 Amazon DynamoDB에 저장된 세부 권한을 확인한다. 이 과정에서도 기존 RBAC와 JWT 기반 신원 검증은 그대로 유지되며, Amazon Bedrock 분석은 그 위에 행동 분석 계층으로 추가된다. 권한 확인을 통과한 요청은 HIPAA 적격 완전관리형 FHIR R4 저장소인 AWS HealthLake에서 데이터를 제공받는다. FHIR 처리 Lambda 함수는 접근 세부 정보를 수집하고 Amazon EventBridge를 통해 이상 분석기, 민감도 분류기, 규정 준수 보고기라는 세 개의 비동기 Lambda 함수로 전달한다. Amazon CloudWatch는 처리 전반의 구조화된 로그를 기록해 감사 추적 자료를 남긴다. 분석은 FHIR 응답이 클라이언트에 반환된 뒤 실행되므로 임상 요청의 API 지연 시간에 영향을 주지 않으며, 분석 계층이 일시적으로 작동하지 않아도 FHIR API는 요청을 계속 처리한다.

4. PHI 보호를 위한 다층 안전장치

AWS CloudFormation 템플릿으로 배포되는 Amazon Bedrock Guardrails는 모델에 전달되는 프롬프트와 모델 응답 양쪽에서 이름, 주소, 전화번호, 의료기록번호 등의 개인식별정보를 탐지하고 익명화한다. 사회보장번호와 여권번호는 익명화하는 대신 완전히 차단하도록 구성된다. 이상 분석 결과를 Amazon CloudWatch Logs에 기록하기 전에는 Amazon Comprehend Medical의 DetectPHI API를 거치며, 발견된 PHI는 실제 값 대신 이름이나 날짜 같은 유형 태그로 치환된다. 원시 IP 주소도 모델에 보내지 않고 RFC 1918 범위를 기준으로 내부 또는 외부 출처로 일반화한다. 고위험 알림에는 환자정보가 아니라 해시 처리된 참조 ID와 위험 수준만 포함되며, 보안 담당자는 해당 ID를 사용해 감사 로그에서 세부 정보를 조회한다. 또한 구조화된 출력의 JSON 스키마와 열거형 필드로 응답 범위를 제한하고, FHIR API 오류는 내부 예외나 HealthLake 응답 대신 일반적인 메시지로 반환해 PHI가 후속 처리나 클라이언트 응답에 섞일 가능성을 낮춘다.

5. 맥락을 반영한 이상 접근 탐지

각 API 호출은 접근 이벤트를 생성하며, 이상 분석 Lambda 함수는 사용자의 역할, 접근 이력, 요청의 성격과 데이터 민감도를 함께 기반 모델에 전달해 위험을 평가한다. 예를 들어 평소 업무 시간에 5~15개의 환자 기록을 조회하던 의사가 오전 3시에 500개 기록을 내려받으면, 개별 역할과 시간 조합에 대한 고정 임계값이 없어도 전체 맥락을 근거로 위험 신호를 만들 수 있다. 반대로 회고 연구를 수행하는 연구자가 한 세션에서 수천 개 기록을 조회하는 행동은 역할, 요청 목적과 정상적인 인증 패턴을 함께 살펴 허가되지 않은 대량 접근과 구분한다. 의사, 간호사, 청구 담당자, 연구자, 외부 연동 시스템은 정상 행동이 서로 다르므로 분석기는 전체 집단에 하나의 기준을 적용하지 않고 사용자별 행동 기준선을 구성한다. 이는 야간 근무 임상의, 해외 연구자, 당직 의사처럼 일반 업무 시간 밖에서 정상적으로 활동하는 사용자를 체계적으로 오탐할 위험을 줄이기 위한 방식이다.

6. 호출자별 기준선과 임상 상황 정보

호출 유형에 따라서도 예상되는 행동과 위험 특성이 다르므로 접근 이벤트에는 OAuth의 client_id가 포함된다. 이를 통해 SMART on FHIR 애플리케이션, 환자 포털, 의료정보교환 연결마다 별도의 애플리케이션 기준선을 유지하고 연동 유형에 따라 위험 점수를 다르게 적용할 수 있다. 조직은 필요할 경우 당직 일정, 응급실 활성화 상태, 진료팀 배정 같은 임상 상황 정보를 접근 이벤트에 추가할 수 있다. 예를 들어 대규모 사상자가 발생한 상황에서 의사가 오전 3시에 500개 기록에 접근한 경우와 평범한 야간에 같은 접근이 발생한 경우는 동일한 위험 평가를 받아서는 안 되며, 프롬프트는 이러한 추가 맥락을 수용하도록 설계된다. 따라서 평소와 다른 접근량이나 시간대 자체만을 위험으로 단정하지 않고, 사용자와 애플리케이션의 역할 및 당시 임상 상황을 함께 평가하는 것이 이 탐지 방식의 핵심이다.

7. 장애 허용 방식과 구조화된 위험 결과

이 구현은 이상 분석 과정에서 오류가 발생하면 실패 사실을 기록하되 원래 API 요청은 차단하지 않는 실패 시 개방 방식을 사용한다. 분석 오류 시 요청을 막는 실패 시 폐쇄 방식 대신 이러한 선택을 한 이유는 보안 분석기의 장애가 환자 진료에 필요한 임상 업무의 가용성 문제로 이어져서는 안 되기 때문이다. 이상 분석기는 Amazon Bedrock Converse API와 구조화된 출력을 사용하며, 위험 수준은 JSON 스키마에서 LOW, MEDIUM, HIGH로 제한된다. 모델 입력과 응답은 Amazon Bedrock Guardrails로 익명화되고, 감사 로그에 기록될 텍스트는 Amazon Comprehend Medical을 통해 다시 PHI가 제거된다. HIGH 위험 이벤트가 발생하면 Amazon SNS는 해시된 참조 ID만 담은 PHI 없는 경보를 전송하므로, 즉각적인 알림 기능과 민감정보 보호를 분리할 수 있다.

8. FHIR 데이터 민감도 자동 분류

FHIR 리소스는 내용에 따라 민감도가 다르며, 정신건강 관찰 결과는 일반적인 혈압 측정보다 더 엄격한 보호가 필요할 수 있고 약물남용 치료 기록처럼 추가 규제가 적용될 수 있는 데이터도 존재한다. AWS HealthLake에서 리소스가 생성되거나 갱신되면 Amazon EventBridge 규칙이 분류 함수를 실행하고, 이 함수는 리소스 유형, 임상 코드, 범주 등의 메타데이터를 Amazon Bedrock에 전달한다. 모델은 결과를 PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED 중 하나로 지정한다. 예시로 혈당을 의미하는 LOINC 코드 2345-7의 Observation은 INTERNAL로, HIV 검사 결과를 의미하는 코드 7018-2의 Observation은 RESTRICTED로 분류된다. 이러한 구분은 코드의 임상적 의미를 바탕으로 하므로 새로운 코드 체계나 리소스 범주가 등장해도 하드코딩된 매핑 표를 코드에서 수정하지 않고 대응할 수 있으며, 분류 결과는 Amazon DynamoDB에 리소스와 함께 저장된다. 다만 이 민감도 분류는 접근 결정을 위한 정보를 제공할 뿐이며, 조직 정책에 따라 별도로 구현해야 하는 동의 관리를 대체하지 않는다.

🧾 핵심 주장 / 시사점

• 기존 RBAC와 JWT 검증을 유지하면서 행동 분석만 비동기로 덧붙이는 구조는 정적 권한 통제와 맥락 기반 탐지를 상호 보완적으로 운용할 수 있게 한다.
• 사용자별·애플리케이션별 기준선에 당직이나 응급 상황 정보를 더하면 단순한 시간·접근량 임계값보다 다양한 임상 업무 패턴을 구분하는 데 유리하다.
• 모델 기반 민감도 분류는 매핑 표 유지 부담을 줄일 수 있지만, 분류 결과가 동의 관리 자체를 대신하지 않으므로 두 통제 영역을 분리해 운영해야 한다.

✅ 액션 아이템

• FHIR 응답 경로와 보안 분석 경로를 분리해 Amazon EventBridge로 접근 이벤트를 비동기 전달하면 임상 API 지연과 가용성 문제를 낮춘다.
• 기존 RBAC와 JWT 검증을 유지한 채 Amazon Bedrock 분석 결과를 EventBridge로 연계해 데이터 민감도 분류와 규정 준수 보고를 정리한다.
• Amazon Bedrock Guardrails와 Amazon Comprehend Medical 조합에서 IP 일반화, PHI 없는 알림, 구조화된 출력, 일반화된 오류 메시지를 적용해 로그·알림 단계의 PHI 노출을 비식별화한다.

❓ 열린 질문

• FHIR 리소스의 유형·임상 코드와 범주를 기반으로 PUBLIC·INTERNAL·CONFIDENTIAL·RESTRICTED를 지정할 때 하드코딩된 매핑 없이 신규 리소스 확장에도 대응 가능한가?
• 이상 분석기가 사용자 역할·과거 접근 행동·요청 성격을 함께 볼 때 비정상적인 시간대·대량 접근을 정상적인 야간 근무나 연구 목적 접근과 어떻게 구분할 것인가?
• Amazon Bedrock Guardrails와 Amazon Comprehend Medical 연계 비동기 분석에서 일반화된 오류 메시지와 PHI 없는 알림이 감사 데이터의 예측 가능성을 유지하면서 PHI 노출을 충분히 차단하는가?