2011-02-01 4 views
6

내 웹 응용 프로그램과 서비스간에 MSMQ와 함께 NServiceBus를 사용하고 있는데 메시지가 로컬 웹 서버 (서비스 호스트가 다운 됨)에 대기중인 경우 중요한 데이터가 될 수 없도록 메시지 페이로드를 암호화 할 수 있어야합니다. 보았다.공개 키잉 서버에 암호화 키는 어디에 두어야합니까?

웹 서버가 공개되어 있기 때문에 어쨌든 디스크에 직렬화 될 수있는 데이터를 암호화해야 할뿐만 아니라 웹 서버에 암호화 키를 저장할 수 없습니다.

DPAPI를 사용하여 키를 저장한다고 생각했지만 키가 호스트에 저장되어 있으므로 요구 사항과 충돌하는지 아직 알 수 없습니다. 내가 고려한 또 다른 옵션은 웹 응용 프로그램이 시작될 때 서비스에서 키를 요청하고 응용 프로그램 풀의 수명 동안 메모리에 보유 할 수 있다는 것입니다.

이전에는 암호화에 대한 요구 사항을 충족하지 못했고 다른 사람들이 무엇을하고 있는지 알아보고 위에서 언급 한 아이디어에 대한 의견을 듣고 싶습니다.

+4

무엇을 하든지 보안 컨설턴트를 고용하여 설계/구현의 유효성을 확인하십시오. 당신이이 분야의 전문가가 아니라면 실수를하는 것이 쉽습니다. 실수를 저지르는 데 비용을 지불하는 것과 비교하여 실수의 비용이 엄청날 수 있습니다. 참조 심장부 지불 시스템. – jason

+1

이것은 비대칭 암호 해독이 해결하는 문제로 나를 공격하지 않습니다. – rook

+0

비대칭 키는 관찰자가 기존 상태를 디스크에서 읽을 확률을 적어도 줄입니다. 비대칭 키를 사용하면 관찰자가이를 사용하여 무차별 공격을 시작할 수 있습니다. – stephbu

답변

0

당신은 NServiceBus가 암호화 키를 가져옵니다되는 소스 대체 할 수 있습니다 -이 여기에 해당 문서에 설명되어 있습니다 : http://docs.particular.net/nservicebus/security/encryption

이 방법이 민감한 정보를 가진 피할 수는 DMZ에 나가있는.

+0

고마워요! 그것이 옵션인지 몰랐습니다. 보안 담당자와 논의한 후에 비공개 서버에서 키를 요청하고 메모리에 저장합니다. –

7

공개 키/개인 키 암호화를 사용할 수 있습니까? 그런 다음 서버의 공개 키 만 있으면되며 데이터는 다른 곳의 개인 키를 사용하여 암호 해독됩니다.

+0

공개 - 개인 암호화는 많은 암호화 보안 엔트로피 (메시지 키, IV 및 패딩 용)가 필요할 수 있습니다. 이는 높은 처리량에서 문제가 될 수 있습니다. – bdonlan

+0

예 동의합니다 - 비대칭 키가 크게 도움이됩니다.충분히 강력한 암호화를 달성하려면 높은 처리량 시스템에서 심각한 마력을 얻을 수 있습니다. 우리는 시나리오 중 하나 인 암호화 하드웨어로 전환했습니다. 비용이 많이 들고 복잡하기 때문에 통합 할 가치가 있습니다. – stephbu

+0

소리가 훌륭하지만 승인 된 비용을받을 수 있는지 잘 모르겠습니다. 독점 하드웨어 없이도 비대칭 암호화가 처리량을 막습니다. 비대칭 키만 사용하는 것이 고려되었지만 키를 해독하는 키는 웹 애플리케이션이 액세스 할 수있는 곳에 저장해야합니다. –

0

encrypt is at the queue level에 가장 적합한 장소. 이 작업은 sending private messages으로 수행하고 비공개 메시지 만 수락하는 대기열을 만듭니다. 생성시 큐를 생성 할 때 큐 개인 정보 수준을 설정할 수 있지만 NServiceBus가 개인 메시지를 보내도록 구성 할 수 있는지 여부는 확실하지 않습니다.

+0

예, 이것을 살펴 보았지만 링크의 문서에 따르면 : "비공개 메시지가 전송되면 메시지 큐는 메시지 본문이 원본 큐 관리자를 떠나는 순간부터 암호화 된 상태로 유지되도록합니다 목적지 큐 관리자에 도달합니다. " 대기열에있는 동안 암호화 된 메시지가 필요하며 MSMQ는 기본적으로이를 지원하지 않는 것 같습니다. –

1

"웹 서버는 공개되어 있으므로 어쨌든 디스크에 직렬화 될 수있는 데이터를 암호화해야 할뿐만 아니라 웹 서버에 암호화 키를 저장할 수 없습니다."

우선주의해야 할 유일한 제약 조건은 다음과 같습니다. 우선적으로 유효한지 확인하십시오. DPAPI + 로컬 키 저장소 접근법을 배제 할 것입니다.

서비스로 키를 전송하는 것이 그럴듯하지만 서비스는 여전히 발신자를 인증해야합니다. 합법적 인 발신자로 위장한 서버가 손상된 경우 전화를 관찰하는 등 모든 작업이 가능합니다. 또한 키만 메모리에 저장 한 경우 해당 메모리는 디버거 또는 메모리 덤프, 승격 된 권한 프로세스 등에서 여전히 검색 할 수 있습니다.

하드웨어 암호화 카드는 후자의 시나리오를 극복하는 유일한 방법입니다.

+0

서비스로 키를 배달하는 것이 맞다고 생각합니다. 웹 서버에 키를 저장할 수 없다는 말을 들었지만 하드웨어 암호화 카드에 대한 승인을 얻지는 못할 것입니다. DPAPI에 대해 더 많이 살펴 봤는데 컴퓨터 범위 대신 사용자 범위를 사용하고 있다면 승인을받을 수 있습니다. 내 매니저는 하루 종일 회의에 참석하고 있으므로 그때까지 승인을 기다려야합니다. –

관련 문제