저장된 VPN 비밀번호: 누가 언제 복호화할 수 있는가

XML에 암호화된 비밀번호를 표시하는 VPN 클라이언트는 당신에게 거의 아무것도 알려주지 않았습니다. 암호문은 그 표현에서 값이 평문으로 저장되지 않았다는 것만 답합니다. 누가, 어떤 키로, 어떤 사용자 컨텍스트에서 복호화할 수 있는지가 그 저장 방식이 도움이 되는지 결정하는 질문입니다. 파일을 안전하다거나 안전하지 않다고 부르기 전에 그 질문에 답하십시오.

어떤 객체가 저장되는지 확정하십시오

제품의 문서화된 저장 모델에서 시작하십시오. 클라이언트는 복구 가능한 비밀번호, 토큰 또는 자격 증명 저장소에 대한 참조를 저장할 수 있으며 각각 노출 수준이 다릅니다. XML 요소 이름은 설계가 아니며 base64처럼 보이는 문자열도 암호화의 증거가 아닙니다.

연결 시점에 어떤 구성 요소가 값을 읽는지 공급업체나 관리자에게 물으십시오.

그다음 문서화되어 있다면 보호 API를 확인하십시오. Windows에서는 CryptProtectData이 암호화하는 사용자의 로그온 자격 증명에서 파생된 키로 데이터를 보호하며, 머신 범위 옵션은 누가 복호화할 수 있는지를 바꿉니다. 범위가 왜 중요한지를 보여주는 구체적인 예입니다. 특정 VPN 클라이언트가 그 API를 쓴다는 증거는 아닙니다.

훔친 사본과 런타임 사용을 구분하십시오

묻지 않고 다시 연결하는 클라이언트에는 자격 증명을 복구할 지원되는 경로가 필요합니다. 백업 사본을 보호해도 그 능력은 사라지지 않습니다. 올바른 사용자 컨텍스트에서 실행되는 프로그램이라면 같은 경로를 사용할 수 있으며, 그래서 엔드포인트 자체가 신뢰 경계 안에 있습니다. 파일 권한과 프로세스 권한은 그 경계를 좁히지만 없애지는 않습니다.

오프라인 파일에 관한 주장이 흔히 틀리는 지점이 이 구분입니다. 저장 시 암호화는 계정 없이 파일 하나를 복사하는 사람을 막을 수 있습니다. 계정으로 실행되는 코드는 막지 못합니다.

두 주장은 동시에 참일 수 있으며, 사고 대응에서 중요한 것은 두 번째입니다.

실제로 적용되는 접근 제어를 읽으십시오

파일의 ACL과 그 상위 디렉터리를 확인하십시오. 파일 모드만 보지 마십시오. Windows에서는 사용자 프로필의 유효 권한을 클라이언트 서비스나 예약된 작업의 권한과 비교하십시오. 한 사용자에게 보호된 비밀은 관리자로부터 자동으로 보호되지도, 관리자에게 자동으로 노출되지도 않습니다.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

복호화의 주체가 바로 그 ID이므로, 어떤 ID가 클라이언트를 실행하는지 기록하십시오.

관리되는 플릿에서는 관련 통제가 파일이 아니라 장치 관리일 수 있습니다. 자격 증명이 위탁 보관되는지, 원격으로 폐기할 수 있는지, 장치를 잃었을 때의 절차가 무엇인지 물으십시오.

복호화를 시험하는 대신 노출에 대비하십시오

주장을 입증하려고 낯선 추출 도구를 파일에 실행하지 마십시오. 동작할 수도 있고 프로필을 손상시킬 수도 있으며, 어느 경우든 증거를 바꿉니다. 검증이 정말 필요하다면 문서화된 설계와 승인된 평가를 사용하십시오.

노출이 확인되면 ID 소유자 쪽에서 자격 증명을 교체하십시오.

저장된 항목을 삭제하는 것은 폐기가 아닙니다. 그 클라이언트가 값을 다시 제공하지 못하게 할 수는 있지만, 이미 확보된 사본이나 이미 승인된 세션에는 아무 효과가 없습니다. 자격 증명을 교체하고, 소유자가 종료할 수 있는 세션을 종료하고, 무엇을 언제 교체했는지 기록하십시오.

공급업체 검토를 위한 질문

어떤 비밀이 저장되는지, 어떤 구성 요소가 사용하는지, 어떤 사용자 또는 머신 키가 보호하는지, 정상 사용과 백업에 어떤 접근 제어가 적용되는지, 저장 정책과 원격 무효화가 어떻게 처리되는지 물으십시오. 그 다섯 가지 답이 설계를 설명합니다. XML은 설명하지 않습니다.

다음 검토자가 같은 작업을 반복하지 않도록 답변을 배포 기록과 함께 보관하십시오.

저장된 자격 증명은 편의와 노출의 맞바꿈입니다. 그 맞바꿈을 의도적으로 하고, 누가 받아들였는지 적으십시오.