암호화 된 데이터베이스 설계 보안

Question

웹 기반 (perl/MySQL) CRM 시스템이 있으며 징계 조치 및 급여에 대한 세부 정보를 추가하기 위해 HR 섹션이 필요합니다.

우리가 데이터베이스에 저장하는 모든 정보는 개발자가 볼 수 없도록 암호화해야합니다.

AES 암호화 사용을 고려하고 있었지만 키로 무엇을 사용합니까? HR 관리자의 비밀번호를 사용하면 비밀번호를 잊어 버리면 모든 HR 정보를 잃게됩니다. 그녀가 암호를 변경하면 모든 정보를 해독하고 새 암호로 다시 암호화해야합니다. 이는 비효율적이며 위험한 것으로 보이며 프로세스의 중간 단계에서 오류가 발생하면 끔찍하게 잘못 될 수 있습니다.

모든 정보를 암호화하는 암호화 키를 가질 수 있고 HR 관리자의 암호를 사용하여 키를 암호화 할 수 있다는 생각이 들었습니다. 그런 다음 그녀는 원하는 모든 암호를 변경할 수 있으며 키를 다시 암호화하면됩니다. (인사 관리자의 암호가 없으면 데이터는 안전합니다.)

그러나 여전히 암호화 된 데이터에 대한 다중 사용자 액세스 문제가 있습니다.

키의 '일반 텍스트'사본을 사이트 외부에 보관하고 새로운 각 인사 담당자의 비밀번호로 암호화 할 수 있습니다. 그런데 이상하게 보이지 않는 마스터 키를 알고 있습니다.

아무도 이것을 시도한 다음 성공 했습니까?

Answer 1

GnuPG를 사용하면 문서를 여러 개의 공개 키를 사용하여 암호화하고 해당 개인 키 중 하나를 사용하여 암호를 해독 할 수 있습니다. 이 방법으로 HR 부서의 모든 사람의 공개 키를 사용하여 데이터를 암호화 할 수 있습니다.복호화는 개인 키들 중 하나를 갖는 임의의 사람에 의해 수행 될 수있다. 암호 해독에는 개인 키와 시스템에 키를 보호하는 암호문이 모두 필요합니다. 개인 키는 시스템 내에서 보유 될 수 있으며 암호는 사용자로부터 요청됩니다.

데이터가 GnuPG에 의해 많은 키를 사용하여 꽤 부 풀릴 수 있습니다 : 페이로드에 대한 세션 키를 생성 한 다음 각 공개 키를 사용하여 해당 키를 암호화해야합니다. 암호화 된 키는 데이터와 함께 저장됩니다.

시스템의 약한 부분은 개인 키가 시스템에서 사용할 수 있어야하므로 (예 : 사용자가 제어 할 수 없음) 암호문이 시스템을 통과해야 해로 훼손 될 수 있습니다 (즉, 기록, 도난) dodgy 코드로. 궁극적으로 원시 데이터도 시스템을 통과하기 때문에 코드를 신경 쓰지 않고 코드를 손상시킬 수 있습니다. 보안을 유지하려면 좋은 코드 검토 및 릴리스 제어가 필수적입니다.

MySQL의 내장 암호화 기능을 사용하지 않는 것이 좋습니다. 복제, 저속 또는 쿼리 로그에 로그인되어 프로세스 목록에 표시 될 수 있으므로 로그 및 프로세스 목록에 액세스 할 수있는 사람은 누구나 액세스 할 수 있습니다. 데이터.

Answer 2

일반적으로 데이터베이스 또는 테이블에 대한 액세스를 제한하지 않는 것이 좋습니다. 훨씬 쉬워 보입니다. 개발자가 프로덕션을 쿼리 할 수있는 권한이 있다면 하루 종일 데이터를 볼 수 없으며 UI는 해시로 데이터를 해독하거나 표시해야합니다.

내가 경험 한 바에 따르면 "개발자는 전혀 생산 데이터를 볼 수 없습니다"를 달성하는 데 필요한 작업량은 엄청나고 거의 불가능합니다. 하루가 끝나면 개발자가 시스템을 지원해야한다면 성취하기가 어려울 것입니다. 프로덕션 문제를 디버그해야하는 경우 일부 개발자가 프로덕션 데이터에 액세스하지 못하게하는 것은 불가능합니다. 대안은 많은 수의 수준과 지원 그룹, 백업, 테스트 데이터 등을 만드는 것입니다.

그것은 잘될 수 있지만 기업주가 생각하는 것처럼 쉽지는 않습니다.

Answer 3

나는 큰 소리로 생각하고있다.

공개 키/개인 키 메커니즘이 필요합니다. 정보는 HR 공개 키로 암호화되어 저장되며 연관된 개인 키를 소유 한 사람 만 볼 수 있습니다.

나에게 이러한 기밀 데이터를 볼 수있는 웹 기반 인터페이스는 배제 된 것으로 보인다. 웹 인터페이스를 통해 입력하는 것이 확실히 가능하다.

개인이오고가는 것을 감안할 때 특정 사람의 계정에 키를 묶는 것은 불가능합니다. 대신 현재 키 관리자가 다른 사람으로 바뀌면 다른 사람이 키 배포를 별도로 처리하고 다른 사람이 사용 된 키 쌍을 변경하고 웹 인터페이스를 사용하지 않고 데이터베이스 —을 다시 암호화하는 메커니즘을 사용해야합니다. 물론 HR 관리자가 키를 교체하기 전에 떠나기 전에 모든 데이터를 덤프하지 못하게하는 것은 없습니다.

Answer 4

또 다른 접근법은 새로운 키를 주기적으로 추가 할 수 있도록 고유 ID를 사용하여 데이터베이스에 저장된 단일 시스템 전체 키를 사용하는 것입니다. 카운터 모드를 사용하면 일반 MySQL AES 암호화를 일반 텍스트를 데이터베이스에 직접 노출하지 않고 사용할 수 있으며 암호화 된 데이터의 크기는 일반 텍스트의 크기와 정확하게 동일합니다. 알고리즘의 스케치 :

1. 응용 프로그램은 레코드에 대해 고유 한 초기 카운터 값을 생성합니다. 이것은 레코드의 고유 한 속성을 기반으로 할 수도 있고이 목적을 위해 고유 한 값을 생성하고 저장할 수도 있습니다.
2. 응용 프로그램은 초기 카운터 값을 기반으로 레코드에 대한 카운터 블록 스트림을 생성합니다. 카운터 스트림은 일반 텍스트와 동일한 크기이거나 최대 1 블록 크기 여야합니다.
3. 응용 프로그램에서 사용할 키를 결정합니다. 키를 주기적으로 회전 시키려면 가장 최근의 키를 사용해야합니다.

4. 카운터 스트림을 암호화하기 위해 데이터베이스로 전송된다 : 어떤

   선택 AES_ENCRYPT hrkeys 행 ('카운터'키) 여기서 KEY_ID = 'ID'등;

5. 암호화 된 카운터 값은 암호화되지 않은 텍스트의 길이로 트리밍되고 일반 텍스트와 함께 XOR되어 암호화 된 텍스트를 생성합니다.

6. 암호화 된 텍스트가 저장됩니다.
7. 암호 해독은 암호화 된 텍스트에 적용되는 절차와 완전히 동일합니다.

이점은 일반 텍스트는 데이터베이스 근처에서 절대 이동하지 않으므로 관리자가 중요한 데이터를 볼 수 없다는 것입니다. 그러나 관리자가 암호화 된 카운터 값 또는 키에 액세스하지 못하게하는 문제가 발생합니다. 첫 번째 작업은 암호화 작업을 위해 응용 프로그램과 데이터베이스간에 SSL 연결을 사용하여 수행 할 수 있습니다. 두 번째는 액세스 제어를 통해 키가 데이터베이스 덤프에 나타나지 않도록하고 키를 메모리 테이블에 저장하여 "건너 뛰기 부여"로 데이터베이스를 다시 시작하여 액세스 제어를 전복하지 못하게 할 수 있습니다. 궁극적으로 이러한 위협을 제거하는 유일한 방법은 암호화를 수행하기 위해 변조 방지 장치 (tamper-proof device, HSM)를 사용하는 것입니다. 필요한 보안 수준이 높을수록 키를 데이터베이스에 저장할 가능성이 줄어 듭니다.

이 현재, 또는 현재의 안정적인 DB 시스템이 지원을 가지고있는,하지만 데이터베이스 수준에서 대체 인증 메커니즘이 도움이 될 방법을 가능한 Wikipedia - Counter Mode

Answer 5

잘 모르겠어요 참조하십시오. 예를 들어, MySQL 코드 기반의 리팩터링 인 Drizzle은 PAM이나 다른 메커니즘을 통해 인증, 서버 내장 인증 또는 인증을 허용하지 않는 완전히 플러그 가능한 인증을 지원합니다 (또는 목표로?). LDAP를 사용할 수 있습니다.

데이터베이스 연결을 기반으로 다른 액세스 수준이 있고 응용 프로그램 로그인이 데이터베이스에서 실제로 액세스 할 수있는 수준을 지정하면 이론적으로 기밀 데이터베이스 정보에 액세스 할 수없는 시스템을 구축 할 수 있습니다 응용 프로그램 자체의 권한 에스컬레이션 시도에 관계없이 특정 액세스 권한이있는 계정을 사용하지 않는 한

사용자 설정 사용자 계정 액세스 권한을 신뢰할 수 있거나 기밀 정보를 볼 수있는 사람이라면 상당히 안전해야합니다.

P. "일반"응용 프로그램 정보에 대해 일반 DB 연결을 사용하는 것이 유용 할 수 있지만 기밀 정보에 액세스하려는 시도가 이루어지면 특정 DB 연결이 시도됩니다. 대부분의 사용자가 기밀 정보를보고 있지 않다는 가정하에 대부분의 요청을 처리 할 수있는 몇 개의 DB 연결을 허용합니다. 그렇지 않으면 사용자 당 별도의 DB 연결이 DB에 부담이 될 수 있습니다.