웹 서버 SSL 개인 키 보호를 관리하는 방법 (암호 및 암호 없음)?

우리 회사의 보안 그룹에서 SSL 개인 키를 관리하기위한 다음 옵션 중 더 나쁜 점에 대해 논의했습니다.

웹 서버는 암호화 작업을 위해 개인 키에 액세스해야합니다. 이 파일은 무단 액세스로부터 보호되어야합니다. 동시에, 사람의 개입없이 서버가 자동으로 시작되어야합니다 (안전한 경우).

우리는 세 가지 옵션을 논의하고 있습니다 :

1. 파일 시스템 권한으로 키를 보호하십시오.

2. 암호로 보호 된 키를 사용하고 다시 시작할 때마다 키를 수동으로 입력하십시오.

3. 비밀번호로 보호 된 키를 사용하고 파일 시스템에 키를 저장하여 재시작을 자동화하십시오.

우리의 관심사는 다음과 같습니다.

1. 옵션 1을 사용하면 재시작이 자동으로 이루어 지지만 보안 침해로 인해 개인 키가 복사 될 수 있으며 보호되지 않은 상태에서 통신을 해독하거나 서버를 가장하는 데 사용될 수 있습니다.

2. 옵션 2가 더 안전 해 보이지만 사람의 개입이 필요하며 업무 외 시간에 시스템 관리자가 걱정하는 경우가 있습니다. 또한 암호는 여러 sysadmin과 공유해야하며 공유 암호는 더 이상 비밀이 아닙니다.

3. 옵션 3은 이전의 두 가지 옵션 중 최고를 가지고 있지만 누군가 키에 액세스 할 수 있으면 암호에 액세스 할 수도 있습니다 : (그래서 전혀 안전하지 않은 것 같습니다.

서버의 개인 키 보안을 어떻게 관리합니까? 더 안전한 다른 옵션이 있습니까?

옵션 1은 인정 된 표준이라고 생각합니다.

당신이 정말로 추가 보안을 원하는 경우, 당신은 왜 당신의 웹 서버를 모니터링하도록 설정 보안 서버 (아닌 DMZ에있는)를 가지고 있지 않으며, 아파치가 다운되면, 그것은 할 수 있습니다 자동으로 원격으로 로그인하고 아파치를 다시 시작 공급, 암호.

따라서 암호문은 컴퓨터에 보관되지만 DMZ가 아닌 아파치가 실행되는 것과 동일하지는 않습니다. 암호를 사용하여 보안을 강화하고 자동 재시작 기능을 유지하십시오.

누군가 키를 읽을 수있는 충분한 서버 액세스 권한이 있으면 디버거를 연결하고 메모리에서 키를 가져올 수있는 충분한 액세스 권한이있을 가능성이 높습니다.

한밤중에 깨어나 암호를 입력하지 않는 한 옵션 1로 이동하십시오. 서버가 많은 경우 실패시 자동 재시작을 원하며 옵션 2에서는 허용되지 않습니다.

1보다 보안은 높지만 다운 타임은 2보다 적을 수있는 한 가지 가능성은 유효성이 짧은 개인 키를 생성하고 정기적으로 재활용하는 것입니다. 그렇게하면 암호없이 저장할 수 있지만 취약성의 범위는 줄어 듭니다.

알다시피, 옵션 3은 1에 대한 추가 보안을 제공하지 않습니다.

실용성은 거의 모든 상황에서 옵션 (1)을 사용하게 될 것이라고 지시합니다. 파일 시스템 파마는 대부분의 보안 대 실제 시나리오에서 가장 좋은 방법입니다.

* nix 시스템에서는 아파치와 같은 대부분의 우수한 웹 서버가 루트로 시작하지만 필요한 권한이있는 포트 (80, 443 등)가 있으면 권한을 제한된 사용자로 다운 그레이드하므로 개인 키를 루트로만 제한 할 수 있습니다. .

옵션 (3)은 보안 관점에서 옵션 (1)과 동일합니다.