데이터베이스의 데이터를 암호화해야합니까?

나는 환자 관리, 환자 관리, 상담, 병력, 달력, 그에 관한 모든 것에 관한 웹 응용 프로그램을 할 클라이언트가 있습니다.

문제는 이것이 민감한 데이터, 환자 이력 등이라는 것입니다.

클라이언트는 데이터베이스 수준에서 데이터를 암호화해야하지만 웹 앱의 성능이 저하 될 것이라고 생각합니다. (그러나 어쩌면 나는 이것에 대해 걱정해서는 안된다)

나는 건강 문제에 관한 데이터 보호에 관한 법률을 읽었지만 (Portugal) 이것에 대해서는 구체적이지 않습니다 (방금 이것에 대해 질문했습니다, 나는 그들의 답변을 기다리고 있습니다).

다음 링크를 읽었 지만 데이터베이스의 데이터를 암호화 해야하는지 여부에 따라 질문이 다릅니다.

데이터 암호화에서 예측하는 한 가지 문제는 키가 필요하다는 것입니다.이 암호는 사용자 암호 일 수 있지만 우리는 모두 사용자 암호 (12345 등) 및 저장해야 할 키 생성 방법을 알고 있습니다. 어딘가에, 이것은 프로그래머, dba, 그것에 접근 할 수있는 것이 무엇이든, 이것에 대한 생각을 의미합니까?

사용자 암호에 임의의 소금을 추가해도 항상 액세스 할 수 있으므로 데이터를 해독 할 수 있기 때문에 문제를 해결하지 못합니다.

나는 이것에 관한 법률을 개인적으로 확인하고 싶습니다. 데이터를 암호화해야하는 경우 암호화해야합니다.

그래도 지침을받지 못하면 환자와 데이터 간의 연결을 보호하는 것이 좋습니다. 즉 PatientID, 데이터베이스 전체의 테이블에서 사용되는 것 같습니다 . PatientID환자, 환자의 병력 등을 식별하지는 못하지만 PatientIDRua de São Bernardo Lisbon에 사는 Joe Bloggs 를 식별하기 위해 가능한 경우 별도의 DB에 보관합니다. 환자의 개인 정보에 TDE를 사용하고 웹 응용 프로그램의 키를 사용하여 TDE를 암호화하십시오.

환자를 식별 할 수단이없는 의료 데이터를 절도하는 것은 굉장히 난처 할 것이지만, 그 이상의 데이터는 없을 것입니다. 말 그대로이 익명의 의료 데이터를 사용하는 온라인 경쟁 이 있습니다.

환자의 개인 정보에서 의료 데이터를 분리합니다. 강력한 역할 세트를 사용하여 직원을 필요한 것만으로 제한하십시오. 환자를 직접 처리해야하는 의료진 (전선 간호사 및 의사)을 제외하고 아무도 두 사람 모두에게 접근 할 수 없습니다. 접수 원은 환자의 개인 정보 만 필요하며, 실험실 직원은 의료 기록 및 환자 ID, 현재 간호사는 현재 의학적 상태 및 이름 만 필요합니다.

각 역할 집합을 식별 한 후에는 웹 응용 프로그램뿐만 아니라 데이터베이스와 추가 보안 계층에서 구현해야합니다.

예, 데이터베이스를 암호화해야합니다.

저장된 데이터 ( "미사용 데이터")에 대한 기본 암호화는 일반적으로 허용되는 보안 원칙이며, 귀하의 국가에 개인 정보 또는 건강 정보를 보호하는 법률이있는 경우 법에 의해 의무화 될 수 있습니다.

우리는 SQL Server 2008을 사용하고 있으므로 Microsoft의 TDE를 사용합니다. MySQL에 대한 타사 솔루션이 있거나 TrueCrypt와 같은 일반적인 볼륨 암호화 방식이 작동 할 수도 있습니다 (데이터베이스와 함께 사용하도록 인증 된 것을 원하지만).

올바르게 수행하면 성능 저하가 적어야합니다.

그건 그렇고, 민감한 정보의 분리와 관련하여 언급 한 링크는 기본 데이터베이스 암호화 위에서 고려해야 할 것입니다.

편집 : 위에서 언급 한 암호화는 볼륨을 암호화합니다. 누군가 하드 드라이브를 훔치면 데이터가 암호화 된 것을 발견 할 것입니다. 그러나 누군가 데이터베이스에서 쿼리를 실행하는 경우 암호화되지 않은 데이터를 볼 수 있습니다 (OP가 이에 대해 논의하고 싶지 않더라도 정보 분리를 언급 한 이유입니다).

이 권장 사항은 최소한으로 수행해야합니다. 법적인 조언을 원한다면 물론 다른 곳을 봐야합니다. 보안 코드 작성에 대한보다 철저한 설명을 원하면 Writing Secure Code 책에서 시작하겠습니다 .

이러한 보안 문제를 결정하기 전에 위협 모델을 평가해야합니다. 무엇을 방어하고 있는지 모를 경우, 취한 조치는 거의 가치가 없을 것입니다.

이제이 상황에서 걱정할 수있는 몇 가지 사항이 있습니다.

• 데이터에 물리적으로 접근하는 공격자 (예 : 데이터 센터 침입, 백업 테이프 훔치기 등)
• 공격자가 원시 데이터베이스에 대한 읽기 권한을 얻습니다.
• SQL 주입, 버퍼 오버런 등을 통해 애플리케이션을 손상시키는 공격자

첫 번째 시나리오의 경우 서버가 헤드리스 상태 인 경우 데이터베이스와 암호화 된 볼륨에 모든 백업을 저장하면 서버를 훔치거나 테이프가 디스크 수준 암호화를 해제해야합니다.

두 번째 시나리오의 경우 데이터베이스 데이터 암호화가 도움이되지만 필요한 키나 암호를 어디에도 저장하지 않은 경우에만 도움이됩니다.

세 번째 시나리오에서는 모든 것이 공격이 발생하는 상황에 따라 달라집니다. 예를 들어 XSS 또는 CSRF 공격 인 경우 공격자는 합법적 인 사용자가 할 수있는 모든 작업을 수행 할 수 있으며 데이터를 암호화해도 전혀 도움이되지 않습니다 .

따라서 위협 모델은 로그인 자격 증명을 찾고 외부에서 데이터베이스 서버에 로그인하거나 데이터베이스 서버에 대한 루트 액세스 권한을 얻어 원시 데이터베이스에 대한 읽기 액세스 권한을 얻는 공격자입니다. 일반적인 경로는 먼저 웹 서버에서 쉘 액세스를 얻는 것입니다. 그런 다음 공격자는 구성 파일에서 액세스 자격 증명을 읽고 데이터베이스에 연결할 수 있습니다.

추가 고려 사항은 특히 PHP와 같은 상태 비 저장 실행 모델이있는 플랫폼을 사용하는 경우 키와 암호를 유지하는 위치입니다. 이상적으로는 고객이 필요할 때 암호를 입력하여 메모리에만 보관하거나 클라이언트 측에서 암호 해독 클라이언트 측을 수행하는 것이 좋습니다 (그러나 종종 실현 가능하지는 않습니다). 상태 비 저장 플랫폼에서 상태는 일반적으로 세션, memcache, 데이터베이스 또는 플랫 파일을 사용하여 전달됩니다. 그러나이 모든 것은 상태 저장 웹 애플리케이션의 자체 메모리에 상태를 유지하는 것보다 훨씬 취약합니다. 이것을 피하는 것은 닭과 계란 문제입니다. 상태를 유지하기 전에 상태를 암호화하면 안전하게 기억해야 할 또 다른 비밀을 만들었 기 때문입니다. 클라이언트의 암호를 기억하고 필요한 각 요청과 함께 전송하면 가장 끔찍한 해결책 일 수 있습니다.

고객이 요구하는 내용과 법률이 무엇인지 잠시 무시합니다.

아니요, 아마도 데이터를 암호화해서는 안됩니다. 그렇게하면 쉽게 검색 할 수 없습니다. 예를 들어, like 'Smith%'모든 이름 항목이 암호화 된 경우 어떻게 성을 검색 합니까? 시간이 지남에 따라 환자의 혈압을 어떻게 그래프로 나타낼 수 select .... from.... where patient_id = N있습니까?

분명히 서버가 제대로 보호되고 네트워크 연결이 보호되며 사용자 인터페이스가 올바르게 보호되어 있는지 확인해야합니다 (세션 시간 초과를 포함하여 사용자는 컴퓨터를 사용하는 사람은 액세스 할 수 있습니다). 데이터베이스 백업을 암호화 할 수도 있습니다. 그리고 서버가 위치한 방을 물리적으로 보호하십시오. 그러나 라이브 데이터는 암호화하지 않습니다.

설명 : 이것은 OP가 요청한 것이 실제로 데이터베이스 의 데이터 를 암호화하는 것으로 가정 합니다. 데이터베이스가있는 파일 시스템이 아닙니다.

CakePHP와 같은 효과적인 MVC 프레임 워크를 사용하여 웹 애플리케이션을 신중하게 개발하는 경우. Zend 또는 Rails 인 경우 데이터 모달 레벨에서 암호화를 활성화 / 비활성화 할 수 있어야합니다.

예를 들어 CakePHP에는 데이터를 암호화하는 모달의 동작에 대한 몇 가지 예가 있습니다. 프로세스를 컨트롤러 및보기에 투명하게 만듭니다.

이 작업을 수행 할 때 인덱싱 및 기타 기술 데이터베이스 문제에 대한 문제를 무시합니다. 이를 구성 가능한 옵션으로 사용할 수 있어야합니다.

또한 나중에 또는 프로덕션 서버에서만 암호화를 설정합니다. 암호화 된 데이터는 개발 중에 디버깅 및 작업하기가 어렵고 특정 열에서만 수행 할 수 있습니다.

예, 데이터베이스를 암호화해야합니다.

이것은 개인 정보와 민감한 정보이므로 반드시 믿어야합니다.

비밀번호에서 세션에 대해서만 저장하는 암호화 키를 파생시킬 수 있습니다. 이렇게하면 아무 곳에도 저장되지 않으며 아무도 암호를 알 수 없으므로 DBA를 포함한 아무도 암호를 알 수 없습니다. DB를 직접 보려고 시도하는 사람은 누구나 횡설수설을 봅니다. 이것을 손상시키는 유일한 방법은 세션 하이재킹을 통하는 것이지만 여기서는 세션이 안전하다고 가정합니다.

클라이언트가 왜 DB를 암호화하라고 요청합니까? 그가 데이터 보호를 요청하면 동의 할 것이지만 이미 암시적인 구현을 염두에두고 있습니다. 그래서 그는 자신이 무슨 말을하고 있는지 정확히 알지 못하는 한 내 관점에서 유행어를 던지고 있습니다.

또한 문자 그대로 모든 주요 DBMS가 보안을 적절하고 아마도 당신보다 더 잘 고려 한다고 확신하기 때문에 DB를 암호화하는 것은 매우 쓸모가 없습니다 . DBMS를 통해 DB에 액세스하려면 자격 증명이 필요합니다. 암호화 된 DB의 경우 해당 자격 증명도 필요하며 데이터를 해독하려면 이미 가지고있는 자격 증명이 필요합니다.

이 사고 방식에 따라 DBMS가 보안을 처리하고 사용자 입력에서 DB 액세스에 이르기까지 자격 증명을 보호하기 위해 강력한 암호와 주기적 변경을 시행 할 것을 제안합니다.