키 암호 문구를 제거할까, 유지할까? 여러분이 만드는 사본

암호화된 개인 키와 암호화되지 않은 키는 같은 키 자료를 담고 있습니다. 변환은 새 신원을 만들지 않고, VPN 계정을 초기화하지 않으며, 이전 파일을 무효화하지 않습니다. 변환은 두 번째 사본을 쓰며, 그 사본은 다른 저장 상태 위험을 지닙니다.

이 교환이 가치가 있는지는 파일이 어디에 있게 되고 누가 읽을 수 있는지에 달려 있습니다.

변환이 실제로 바꾸는 것

변환 전에는 운영자가 제공하는 암호 문구가 키를 보호합니다. 변환 후에는 파일 시스템 권한과 파일을 둘러싼 모든 접근 제어가 키를 보호합니다. 암호학은 바뀌지 않았고, 공격자와 키 사이에 서 있는 것의 수가 바뀌었습니다. 그게 전부입니다.

표로 만들면 차이가 구체적이 됩니다.

어느 형태도 자동으로 더 안전하지는 않습니다. 둘은 서로 다른 방식으로 실패하며, 그중 한 방식만 로그 기록을 남깁니다.

암호 문구를 유지하는 편이 나은 경우

지원되는 클라이언트가 암호 문구를 요청하거나 승인된 비밀 저장소에서 가져올 수 있다면 변환은 아무것도 사지 못합니다. 사본 하나, 보호 경계 하나, 추적할 파일 하나를 줄이게 됩니다. PEM 키를 받아들이는 대부분의 VPN 클라이언트가 이렇게 할 수 있습니다.

팀이 키를 공유할 때도 변환은 잘못된 선택입니다. 공유 호스트의 암호화되지 않은 파일은 셸 접근 권한이 있는 누구나 복사할 수 있는 자격 증명이 됩니다.

암호화되지 않은 사본이 정당화되는 경우

일부 서비스는 요청할 수 없고, 일부 컨테이너는 비밀을 읽기 전용으로 마운트하며, 일부 장비는 부팅 시 대화형 경로 없이 키 파일을 읽습니다. 그런 경우에는 적절히 제한된 디렉터리 안의 암호화되지 않은 키가 지원되는 설계일 수 있습니다. 정당성은 환경이지 편의가 아닙니다.

누가 파일을 읽을 수 있는지, 왜 그런지 말할 수 없다면 답은 아니요입니다.

명령과 그 날카로운 모서리

OpenSSL 3.5가 지원하는 파일 기반 키의 경우, pkey 참조 는 입력이 암호화되어 있고 암호 원본이 제공되지 않을 때의 암호 문구 제거와 대화형 프롬프트를 문서화합니다. 최소 형식은 짧고, 부주의하게 실행하기 쉽습니다.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

세 가지 날카로운 모서리. 출력 파일 I/O는 원자적이지 않으므로 기존 출력 경로가 쓰기 도중에 잘릴 수 있습니다. 입력 경로를 출력으로 사용하지 말고, 유일하게 보호된 사본에서 실험하지 마세요. 암호 문구는 셸 기록에 남는 명령줄이 아니라 프롬프트에서 입력하세요.

VPN 구성을 변경하기 전에 결과를 확인하세요: openssl pkey -in new-private-key.pem -pubout 는 이전과 같은 공개 키를 출력해야 합니다.

변환이 하지 않는 일

변환은 암호화된 사본을 철회하지 않습니다, 그 사본은 여러분이 두고 온 곳에 여전히 있습니다. 변환은 VPN 계정 암호나 인증서를 바꾸지 않습니다. 그리고 이미 발생한 노출을 복구하지 않습니다. 키가 유출되었다면 해결책은 교체와 서버 측 철회이지, 로컬 형식 변경이 아닙니다.

중간 파일을 의도적으로 삭제하고, 삭제하는 경로가 여러분이 만든 경로인지 확인하세요.