OpenVPN CA 서명 키를 /etc/openvpn 밖에 두십시오

튜토리얼에서 비슷해 보이는 두 디렉터리는 전혀 다른 일을 합니다. 하나는 인증 기관을 보관하며, 그 개인 키, 일련번호 카운터, 서명한 모든 것의 기록을 담습니다. 다른 하나는 데몬이 시작하고 클라이언트를 응대하는 데 필요한 것을 보관합니다. 둘을 같은 호스트의 같은 계정 아래 두는 것은 한나절 동안은 편하지만, 데몬이 원하는 어떤 신원이든 발급할 수 있는 유일한 키 옆에서 돌아가게 되므로 배포의 남은 수명 전체에는 비쌉니다.

CA 작업 공간에 들어 있는 것

PKI 디렉터리는 발급자의 상태이지 설정이 아닙니다. CA 개인 키와 인증서, 일련번호 파일, 발급된 인증서 색인, 그리고 그것들로 만든 각 신원의 자료를 담습니다.

요청에 서명하면 그 상태가 바뀌므로 작업 공간은 VPN 서비스가 돌지 않는 호스트의 관리자 통제 계정에 속합니다. CA 개인 키를 읽을 수 있는 사람은 서버가 신뢰할 인증서를 발급할 수 있으므로, 키 보호가 한 파일에 담긴 신뢰 모델 전부입니다. 한 단계를 아끼려고 다른 위치로 복사하면 보호할 두 번째 것과 잊을 두 번째 것이 생깁니다. 서명할 때마다 일련번호가 늘고 색인에 항목이 추가되므로 작업 공간은 파일 폴더가 아니라 상태의 한 사본입니다.

공개 CA 인증서는 다릅니다. 배포되도록 만든 것이며, 클라이언트와 서버가 서로를 검증하는 데 쓰는 것입니다.

데몬이 시작할 때 읽는 것

실행 중인 서버는 자기 인증서, 자기 개인 키, 피어 검증용 CA 인증서, 선택한 모드가 요구하는 키 자료라는 작은 집합을 소비합니다. 이 경로들을 시작할 때와 다시 불러올 때 읽습니다.

소유권은 실제로 기동하는 유닛을 기준으로 평가해야 하며, 대화형 root 셸을 기준으로 해서는 안 됩니다. 선언된 샌드박싱은 root로 한 수동 테스트가 성공하더라도 파일 시스템의 일부를 읽기 전용이나 보이지 않게 만들 수 있습니다.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

세 번째 줄이 사람들이 건너뛰는 줄입니다. 데몬 자신의 계정에 키를 읽을 수 있는지 묻는 것이며, 권한을 내린 뒤에 의미가 있는 유일한 질문 형태입니다. root로 종료 코드 영을 받는 것은 권한을 내린 뒤 무슨 일이 일어나는지에 대해 아무것도 알려주지 않습니다.

권한을 바꾸기 전에 두 고장 경로를 구분할 가치가 있습니다. 서명 실패는 PKI 디렉터리, 그 상위 디렉터리의 검색 권한, 발급자를 실행하는 계정을 가리킵니다. 시작 실패는 유닛, 그 작업 디렉터리, 서버 설정에 적힌 경로를 가리킵니다. 트리 전체를 모두 읽을 수 있게 만드는 것은 둘 중 어느 것도 고치지 못하고, 둘 다 의존하는 경계를 없앱니다.

CA 키를 서버로 복사하면 나중에 실패하는 이유

복사는 보통, 누군가 VPN 호스트에서 클라이언트를 갱신하려다 CA 키가 /etc/openvpn 에 들어가고 갱신이 되는 디버깅 조치로 시작됩니다. 당장의 일은 성공하고 경계는 사라집니다.

그다음 서버가 백업되고 서명 기관이 백업에 들어갑니다. 스냅숏, 지원 번들, 또는 설정 디렉터리 사본이 이제 CA가 유효한 동안 신뢰받는 신원을 발급할 능력을 지닙니다. 그 사본을 가진 사람은 서버가 받아들이는 어떤 이름의 인증서든, 한 번도 발급된 적 없는 이름까지 포함해 만들 수 있습니다. 그 발급의 유일한 기록은 그들이 남기기로 선택한 것입니다.

그 상태에서 복구하는 것은 파일을 지우는 문제가 아닙니다. 키가 노출되었는지 결정하고, 노출되었다면 CA를 교체하고, 모든 피어에 신뢰를 다시 배포해야 합니다. 작업 공간을 분리해 두면 그 대화 자체가 일어나지 않습니다.

계정, 디렉터리, 백업

발급자에게 자체 계정과 홈 디렉터리를 주고, 가능하면 VPN 호스트 밖에 두십시오. 데몬에게는 다른 계정을 주고, 배포된 자료에 대한 읽기 권한만 주며 인증서를 발급하는 어떤 것에도 쓰기 권한을 주지 마십시오. 배포는 공개 인증서를 밖으로 복사해서 하고, 발급자의 개인 상태를 안으로 끌어오는 일은 절대 하지 마십시오. 두 역할은 민감도와 복원 이야기가 다르므로 따로 백업하십시오.

폐기 후에는 서버 설정이 지목하는 CRL 파일을 갱신하고, 그다음 서비스를 다시 불러와 새 연결이 그것을 읽게 하십시오. Easy-RSA 문서가 작업 공간 배치와 서명 흐름을 다루며, 그 주변의 소유권 규칙은 여전히 호스트에 관한 결정입니다. 서비스가 무엇을 읽었는지는 다시 불러오기가 집어 들었다고 가정하지 말고 openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate 로 확인하십시오.

분리를 증명하는 시험

작동하는 경우만이 아니라 부정적인 경우를 확인하십시오. 설계대로 발급자 계정에서 인증서에 서명한 뒤, 같은 계정이 서비스를 시작할 수 없고 서버의 개인 키를 읽을 수 없음을 확인하십시오. 다음으로 데몬의 계정이 CA 개인 키를 읽을 수 없음을 확인하십시오.

이 세 검사는 몇 분이면 끝나고, 습관이 아니라 권한에 대한 진술이므로 직원이 바뀌어도 버팁니다. 결과는 대상 경로와 계정, 실행한 날짜와 함께 적으십시오. 그렇지 않으면 이 배포를 물려받는 다음 사람이 경계가 애초에 없던 튜토리얼에서 경계를 다시 도출하게 됩니다. 날짜가 있는 기록은 다음 검토를 한나절이 아니라 몇 분으로 만드는 것이기도 합니다.