나는 우리 MySQL 데이터베이스의 보안을 강화하기 위해 노력하고 있습니다. 특히, 데이터베이스는 고객의 환자 (소위 PHI)의 건강 정보를 저장하며 환자의 이름과 기타 식별 정보를 건강 데이터에서 분리하고자합니다. 이 문제에 대한 접근 방법은 무엇입니까?민감한 데이터를위한 MySQL 데이터베이스 보안
저는 여러 가지 식별 데이터를 묶는 데 필요한 하나의 키를 유지하고 건강 정보를 연결하는 또 다른 키를 생각했습니다. 이들은 임상 사용자가 로그인 할 때만 사용할 수있는 특별한 "코딩 된 키"로 서로 매핑됩니다. 누구나 그런 접근 방식에 대한 생각을 갖고 있습니까?
건강 정보 (dx, 증상, 제공자, 지불 등)와 개인 식별 정보를 결합하는 것은 PHI입니다. PHI에 대한 자세한 내용은 discussion입니다. PII는 모든 종류의 것을 포함 할 수 있습니다.
PHI의 보호 측면에서 HIPAA는 그것에 대해 규정하지 않습니다. 그것은 HIPAA의 주요 문제점 중 하나이며 HITRUST가 업계에서 잘하고있는 이유입니다. 보안 관점에서 바라본 추론은 많은 의미를 갖지만 궁극적으로 보안은 규정 준수와 다릅니다.
Catalyze 우리는 타사 감사원을 사용하여 HIPAA 감사 2 건과 HITRUST 감사/평가 1 건을 경험했습니다. 설명 된 방식과 마찬가지로 PII 및 상태 데이터를 분할하기 위해 API를 설계했습니다. 우리의 감사관은 픽업이 불필요하다고 생각했지만 그것이 PHI 위반의 위험을 완화하는 추가 방법이라고 느꼈습니다. 결국 우리는 플랫폼의 모든 데이터를 PHI로 취급하고 적절하게 보호하므로 우리에게 준수하도록 데이터를 분할하는 문제는 아닙니다. 최종 감사 보고서에서 PII를 건강 데이터에서 분류하는 것은 HIPAA의 특정 요구 사항을 다루지는 않았지만 전반적인 보안 상태의 일부로 언급되었습니다.
희망 하시겠습니까?
저는 보안 전문가가 아니기 때문에 환자 데이터와 관련하여 준수해야하는 현지 법률 가이드 라인이있을 수 있지만 보안을 유지하는 방법은 모든 데이터를 함께 보관하는 것입니다. 하나의 테이블 - 관련 사용 권한을 가진 사용자에게만 액세스 권한을 부여합니다. 관련 권한이없는 사용자 (그러나 '익명화 된'데이터 또는 요약 통계에 액세스하려는 사용자는 해당 데이터의보기 (하위 집합)에 액세스 할 수 있습니다.) – Strawberry
우리가 방지하려고하는 것은 누군가가 데이터베이스에 침입 할 수 있고, 단순히 모든 테이블의 기본 키와 외래 키를 사용하여 모든 환자 식별 데이터와 건강 데이터를 수집합니다. 두 테이블 세트 사이에 특별한 매핑 테이블을 배치하면 제 생각에 "특수 키 "유효한 로그인 한 사용자 만 액세스 할 수 있습니다 (특수 키는 OpenSSO/OpenAM과 같은 것으로 저장 될 것입니다). – KenBoyer
이 작업을 정확하게 수행하려고 시도한 결과 불확실한 용어로는이를 준수하지 않는다고 통보 받았습니다 HIPAA, ARRA, HITEC 또는 ISO-29001 인증을받은 환자는 PHI 감사원이 불충분하고 불필요하다고 결론을 냈습니다. 왜? 환자의 진단, 생년월일, 체중, Rx 또는 객실 번호가 의료 기록과 분리되었습니다. 마비 된 어 또는 이름은 PHI입니다. 실망! –