짧은 답변: 건강 앱의 보안은 네 가지 질문에 순서대로 답합니다. 이 사람은 누구인가? 신원 확인: OpenID Connect를 통해 인증된 사용자(환자, 의료진, 시스템)이며, 의료진의 경우 국가 전문 신원 확인. 비밀번호 강도보다 인증 수준이 더 중요합니다. 무엇을 할 수 있는가? 권한 부여: 목적과 기간에 대한 환자의 동의에서 파생된 SMART on FHIR 구문의 **범위(scope)**를 가진 OAuth 2.0 (2.1로 전환 중) 토큰으로, 데이터 계층에서 강제 적용됩니다. 무엇을 했는가? 책임 추적: 환자가 읽을 수 있는 접근 로그와 조직을 위한 FHIR AuditEvent 추적. 데이터는 저장 중, 전송 중, 백업 시 안전한가? 보호: 암호화, 키 관리, 분리, 테스트된 복구. 이 모든 것을 뒷받침하는 것은 ISO 27001 및 27799, NIS2 및 HIPAA 보안 규칙의 기본 사항과 건강 데이터의 특정 위협(내부자 열람, 잘못된 파일링, 랜섬웨어)입니다.
로드맵
건강 앱의 보안 및 신원 확인은 7가지 계층으로 구성됩니다. OpenID Connect 및 국가 또는 전문 ID를 통한 신원 확인, OAuth 2.0 및 SMART on FHIR 범위를 통한 권한 부여, 모든 승인의 출처로서의 동의, 액세스 로그 및 FHIR AuditEvent를 통한 책임 추적, 암호화 및 백업을 통한 보호, ISO 27001, ISO 27799, NIS2 및 HIPAA를 기반으로 하며, 환자가 시작하는 공유입니다.
| 계층 | 표준 또는 관행 | 제공하는 것 | 페이지 |
|---|---|---|---|
| 신원 확인 | OpenID Connect; 국가 신원 확인(eIDAS, NHS login, GesundheitsID); 전문 신원 확인(eHBA, CPS, UZI) | 보증 수준이 있는 인증된 주체 | SMART 앱 실행 설명 |
| 권한 부여 | OAuth 2.0 및 2.1 (PKCE 필수, 암시적 또는 비밀번호 부여 없음); SMART on FHIR 범위(patient/Observation.rs); 비대칭 클라이언트 인증을 사용하는 백엔드 서비스 | 사용자, 환자 컨텍스트 및 범위에 바인딩된 토큰 | SMART 앱 실행 설명, SMART on FHIR 백엔드 |
| 동의 | FHIR Consent; 목적 및 시간 제한 부여; 철회; 정당화 및 경고를 통한 긴급 접근(break-the-glass) | 모든 권한 부여의 출처로서의 환자 | 환자 동의 플랫폼, 진료소 접근 요청 |
| 책임 추적 | 환자가 볼 수 있는 기록별 접근 로그; FHIR AuditEvent; 변조 방지 저장소; 보존 기간 | 누가, 무엇을, 언제 보았는지 | 내 의료 기록을 누가 보았습니까? |
| 보호 | TLS 1.2 이상, 관리 키를 사용한 저장 데이터 암호화, 식별자를 위한 필드 수준 암호화, 분리된 환경, 테스트된 복구를 포함한 백업 | 기밀성 및 가용성 | ISO 27001 vs ISO 27799 |
| 기본 | ISO 27001 ISMS, 27799 건강 관리 제어, NIS2 조치, HIPAA 보안 규칙, 국가 계획(HDS, DSPT, C5) | 병원, 감사자 및 규제 기관이 기대하는 것 | 병원 및 공급업체를 위한 NIS2, HIPAA vs GDPR |
| 공유 | SMART Health Links 및 Cards; 검증 가능한 자격 증명 | 링크 또는 QR 코드를 통한 환자 주도 공유, 철회 가능 | SMART Health Links 설명 |
신원 확인: 비밀번호보다 보증 수준
건강 앱의 신원 확인은 비밀번호 강도보다 보증 수준에 따라 달라집니다. NIST IAL, eIDAS substantial 및 high, 또는 NHS login P9와 같은 신원 보증 수준은 등록 시 개인의 신원이 얼마나 강력하게 확인되었는지를 설명하며, 다단계 인증 및 패스키는 각 로그인 시점을 설명합니다. 의료진은 퇴사 시 해지되는 전문 신원을 통해 식별됩니다.
전체 기록을 표시하는 환자 앱은 해당 환자와 통신하고 있음을 알아야 합니다. 신원 확인 수준(NIST의 IAL, eIDAS 실질 및 높음, NHS login P9)은 등록 시 신원이 얼마나 강력하게 확인되었는지를 설명합니다. 인증 강도(다단계 인증, 패스키)는 각 로그인을 설명합니다. 병원 및 국가 시스템은 자체 선언된 가입보다 인정된 계획의 인증된 신원을 점점 더 요구하고 있으며, EU 디지털 신원 지갑은 인정되는 수단이 될 것입니다. 의료진의 경우, 전문 신원 확인(그리고 직원을 그만둘 때의 철회)은 누가 의료진으로 활동할 수 있는지에 대한 기록 시스템입니다.
권한 부여: 동의가 범위로
환자 통제 기록에서의 권한 부여는 환자의 동의를, 예를 들어 특정 병원이 90일 동안 검사 결과 및 질병 기록을 읽도록 허용하는 것을, OAuth 범위와 토큰의 환자 컨텍스트로 변환하며, SMART on FHIR 구문(예: patient/Observation.rs)으로 표시됩니다. 이는 모든 요청 시 데이터 계층에서 강제 적용되며 환자가 철회하면 해지됩니다. Break-the-glass는 별도의 감사 경로입니다.
환자 통제 기록에서 환자의 동의는 정책입니다. 이 진료소는 90일 동안 내 검사 결과와 질병을 읽을 수 있습니다. 시스템은 이를 OAuth 범위와 컨텍스트(어떤 환자, 어떤 리소스, 어떤 작업)로 변환하여 진료소 시스템이 받는 토큰에 담고, 데이터 계층에서 모든 요청에 대해 이를 강제하며, 환자가 철회할 때 이를 철회합니다. SMART on FHIR의 범위 구문(patient/Observation.rs, patient/Condition.rs)은 이를 위한 공용어입니다. 세분화된 범위(범주 또는 코드별)는 더 세밀한 제어를 위해 SMART v2에 존재합니다. 긴급 접근(break-the-glass)(동의 없이 긴급 접근)은 정당화 및 환자에게 경고가 의무화된 별도의 감사 경로이며, 기본값은 절대 아닙니다. 환자 동의 플랫폼을 참조하십시오.
책임 추적: 환자가 읽는 로그
건강 앱에서의 책임 추적은 기록에 대한 모든 액세스(누가, 언제, 무엇을, 어떤 동의 하에)가 환자가 앱에서 읽을 수 있는 추가 전용 로그와 FHIR AuditEvent의 조직 감사 추적에 기록됨을 의미합니다. ISO 27799는 이를 필수 사항으로 취급하며, 보이는 로그는 내부자의 무단 열람에 대한 가장 강력한 억제책입니다.
기록에 대한 모든 접근, 누가, 언제, 무엇을, 어떤 동의 하에 접근했는지, 환자가 앱에서 읽을 수 있는 추가 방지 로그와 보안 팀을 위한 조직 감사 추적(FHIR AuditEvent)에 기록됩니다. ISO 27799는 이를 건강 정보에 대해 필수 사항으로 취급합니다. GDPR의 투명성 원칙과 EHDS의 환자 권리도 같은 방향을 가리킵니다. 내부자 열람에 대한 가장 큰 실제 억제책은 보이는 로그입니다. 내 의료 기록을 누가 보았습니까?를 참조하십시오.
보호: 엔지니어링 기본 사항
건강 데이터를 보호하기 위한 엔지니어링 기본 사항은 모든 곳에서의 TLS, 관리 및 순환되는 키를 사용한 저장 데이터 암호화, 직접 식별자에 대한 별도의 암호화 또는 토큰화, 프로덕션 외부의 합성 데이터를 사용한 분리된 환경, 관리자를 위한 다단계 인증을 통한 최소 권한 액세스, 비밀 및 취약점 관리, 랜섬웨어에 대한 복원 테스트를 거친 암호화된 백업, 그리고 GDPR 및 NIS2 시간 내의 사고 대응입니다.
모든 곳에 TLS를 사용하며, 최신 암호 및 앱의 인증서 고정(적절한 경우)을 사용합니다. 관리형 키 서비스 및 로테이션의 키를 사용한 저장 데이터 암호화; 직접 식별자를 위한 별도의 암호화 또는 토큰화; 프로덕션과 개발 환경 분리, 프로덕션 외부의 합성 데이터 사용; 직원에 대한 최소 권한 액세스, 공유 계정 없음, 모든 관리 액세스에 대한 다단계 인증; 비밀 관리; 공개를 포함한 종속성 및 취약성 관리; 백업은 암호화되고 복구 테스트를 거치며, 병원 및 실험실을 반복적으로 강타한 랜섬웨어(2017년 WannaCry, 2020년 뒤셀도르프 병원, 2024년 Change Healthcare 및 Synnovis)로부터 보호됩니다. 72시간 GDPR 및 24시간 NIS2 시간을 하나의 실행 계획으로 처리하는 사고 대응.
건강 데이터에 특화된 위협
건강 데이터에 특화된 위협은 지인의 기록에 대한 내부자 무단 열람, 환자 간의 잘못된 기록 분류, 너무 오래 허용된 과도하게 넓은 공유 범위, 건강 데이터를 처리하는 앱 내 광고 SDK, AI 기능으로의 문서 삽입, 그리고 수십 년 동안 키, 형식 및 액세스 규칙이 직원 및 공급업체를 능가해야 하는 장기 보존입니다.
- 내부자 열람: 지인 또는 유명인의 기록 열람: 관계 기반 액세스 및 보이는 로그.
- 잘못된 파일링: 환자 간의 잘못된 파일링: 액세스 제어뿐만 아니라 신원 확인 및 출처 추적.
- 과도한 공유: 1년 동안 "모든 것"을 부여받은 진료소; 합리적인 기본값을 가진 범위 및 기간.
- 광고 SDK가 포함된 앱: 건강 데이터를 처리하는 모든 앱에 제3자 추적기 없음.
- AI 기능에 대한 문서 기반 주입: 콘텐츠는 데이터이지 지침이 아닙니다(의료 기록에 대한 RAG).
- 장기 보존: 기록은 수십 년 동안 유지됩니다. 키, 형식 및 액세스 규칙은 직원 및 공급업체를 능가해야 합니다.
Anpheros에서
Anpheros는 앱의 경우 PKCE를 포함한 OAuth 2.0과 백엔드의 비대칭 클라이언트 인증, 모든 병원의 액세스 출처로서 목적 및 기간별 동의, 개인의 앱에 기록별 액세스 로그, 저장 및 전송 중 암호화, EU 호스팅, 광고 SDK 미사용, 그리고 ISO 27001 및 27799에 따른 ISMS를 자체에 적용합니다.
Anpheros는 이 로드맵을 자체에 적용합니다. 앱의 경우 PKCE를 사용하는 OAuth 2.0, 백엔드의 경우 비대칭 클라이언트 인증. 모든 진료소의 액세스 출처로서 목적 및 기간별 동의, 철회 기능 및 자동 긴급 접근 없음. 개인의 앱에 기록별 접근 로그. 저장 및 전송 중 암호화, EU 호스팅, 광고 SDK 없음. ISO 27001에 따른 ISMS와 27799 건강 관리 제어를 포함합니다. 개발자 사이트에는 인증, 동의 및 보안이 문서화되어 있습니다.
관련 페이지
- SMART 앱 실행 설명
- 환자 동의 플랫폼
- 내 의료 기록을 누가 보았습니까?
- SMART Health Links 설명
- ISO 27001 vs ISO 27799
- 병원 및 건강 기술 공급업체를 위한 NIS2
- 플랫폼 보안 (개발자 사이트)
- 인증 (개발자 사이트)
출처
- HL7 SMART App Launch
- IETF: OAuth 2.1 (초안)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: 병원 사이버 보안 조달 지침
자주 묻는 질문
OAuth 2.1은 2.0과 다른가요?
OAuth 2.1은 2.0과 보안 모범 사례를 통합합니다. 모든 클라이언트에 PKCE가 필수이며, 암시적 및 비밀번호 부여는 제거되고, 리디렉션 URI는 정확히 일치해야 하며, 퍼블릭 클라이언트에 대한 새로 고침 토큰은 바인딩되거나 순환되어야 합니다. SMART on FHIR v2는 이미 이러한 요구 사항의 대부분을 충족합니다.
긴급 접근(break-the-glass)이란 무엇인가요?
환자의 사전 동의 없이, 정당성을 주장하는 의료진이 기록에 접근하는 긴급 상황입니다. 이는 드물어야 하며, 기록되고, 검토되고, 환자에게 보고되어야 합니다. 절대 기본 접근 경로는 아닙니다.
환자가 접근 로그를 봐야 하는 이유는 무엇인가요?
부적절한 접근에 대한 가장 강력한 억제책이자 통제권을 가장 명확하게 표현하는 방법이기 때문입니다. 환자는 어떤 진료소가 언제 무엇을 읽었는지 확인하고 철회할 수 있습니다. ISO 27799와 EHDS도 같은 방향을 가리킵니다.
별도의 감사 시스템이 필요한가요?
애플리케이션이 수정할 수 없는 추가 방지 감사 추적(FHIR AuditEvent 또는 이에 상응하는 것)이 필요하며, 정책에 따라 보존되고, 이를 기반으로 하는 환자 대상 보기가 필요합니다. 별도의 시스템인지 플랫폼 내부의 보호된 저장소인지는 구현 선택 사항입니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →