VPN APT 소스: 무엇을 허용하며 어떻게 제한할 것인가

VPN 클라이언트를 내려받는 것은 일회성 결정이지만, 그 APT 저장소를 추가하는 것은 그렇지 않습니다. 후자는 향후 소프트웨어가 어디서 올 수 있는지를 패키지 관리자에게 알려 주며, 이는 다운로드가 아니라 권한의 영구적인 이전입니다. 공급업체가 저장소를 제대로 유지한다면 그것이 올바른 방식일 수 있습니다. 그래도 그것은 의식적인 결정을 받을 만하며, 대부분의 설치 안내서는 이 부분을 건너뜁니다.

서명은 코드가 아니라 아카이브를 인증한다

APT는 서명된 저장소 메타데이터를 검증한 다음, 가져오는 패키지에 대해 그 메타데이터 안의 체크섬을 신뢰합니다. 이것이 증명하는 것은 아카이브가 키 소유자가 게시한 것과 일치한다는 점이며, 그 안의 코드에 대해서는 아무것도 아닙니다. 올바르게 서명된 패키지도 안전하지 않은 유지관리 스크립트를 담을 수 있고, 그 스크립트는 패키지가 설치되는 동안 root로 실행됩니다. apt-secure 설명서는 아카이브 인증과 소프트웨어 검토 사이에 바로 이 경계를 긋습니다.

따라서 유용한 질문은 서명이 유효한지가 아니라, 깨진 서명은 어차피 설치를 멈추므로 이제부터 누구의 서명을 신뢰할 것인가입니다. 도난당한 서명 키는 도난당한 패키지보다 나쁩니다. 공격자가 첫 번째 나쁜 릴리스 이후에도 오랫동안 유효한 메타데이터를 계속 만들어 낼 수 있기 때문입니다. 유일한 복구는 키 교체이며, 그것은 공급업체가 독립적으로 검증할 수 있는 경로로 새 키를 게시하는지에 달려 있습니다.

그래서 키의 신원은 저장소 URL만큼 주의를 받을 만합니다. 오래된 포럼 답변의 주소에서 가져온 키는 게시자에 대해 아무것도 입증하지 못하며, HTTPS는 전화를 받은 사람까지의 전송만 보호합니다. 전송 보안과 게시자 신원은 별개의 문제이고, 인증서가 해결하는 것은 첫 번째뿐입니다.

키를 시스템이 아니라 소스로 한정하라

현대의 APT는 소스별 Signed-By 참조를 받아들입니다. 운영자가 관리하는 키는 /etc/apt/keyrings/ 아래에 둘 수 있고, 소스 항목은 그 아카이브를 인증할 수 있는 키를 지정합니다. 이는 같은 키를 전역 신뢰 집합에 넣는 것보다 좁습니다. 거기서는 허용할 생각이 없던 소스까지 보증할 수 있기 때문이므로, 서로 다른 세대의 안내서 조각을 섞지 말고 설치된 APT 버전과 공급업체의 현재 지침을 따르십시오.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

검증을 끄거나 알 수 없는 아카이브를 신뢰됨으로 표시하여 서명 실패를 고쳐서는 안 됩니다. 그것은 보이는 오류를 보이지 않는 오류로 바꾸는 것이고, 보이지 않는 오류는 누군가 소스 목록을 감사할 때까지 계속됩니다. 키가 맞지 않으면 올바른 수정은 올바른 키를 찾는 것이지 검사를 없애는 것이 아닙니다.

저장소 세부 정보와 키의 신원은 프로젝트나 관리되는 관리자에게서 받으십시오. 블로그 글에서 복사한 키는 저자에 대한 주장이지 그 증거가 아닙니다. 공급업체가 교체 경로를 게시하면 다음 교체를 가능하게 하는 것이 바로 그 경로이므로 키와 함께 기록해 두십시오.

소스 고정은 패키지 허용 목록이 아니다

키를 하나의 소스로 제한하면 그 키가 인증할 수 있는 아카이브가 제한될 뿐, 그 아카이브가 게시할 수 있는 패키지가 제한되는 것은 아닙니다. 저장소는 원하던 VPN 클라이언트보다 훨씬 많은 것을 보낼 수 있고, 어떤 적격 버전이 이길지는 APT의 후보 선택과 우선순위가 결정합니다. 의존성도 같은 아카이브에서 오므로, 확인하기 전에 의존성 목록을 포함해 제안된 트랜잭션을 검토하십시오. 키의 범위는 ’이 패키지만’을 표현할 수 없습니다.

더 강한 통제가 필요하면 패키지 이름이나 버전에 대한 정책으로 표현하고 그 정책을 구성 관리 아래에 두십시오. 트랜잭션을 읽는 데 일 분이 걸리고, 여섯 달 뒤 예상치 못한 패키지를 발견하는 데 검토 한 번이 걸립니다.

예상치 못한 패키지는 진행할 때가 아니라 멈출 때이며, 아카이브 소유자에게 할 질문은 왜 그것들이 필요한가입니다. 한 클라이언트를 중심으로 십여 개의 패키지를 게시하는 것은 데스크톱 제품군을 내놓는 공급업체에게 정상입니다. 그것은 설치 안내서가 시사한 것보다 넓은 표면이기도 하며, 기록할 가치가 있는 부분이 바로 이것입니다. 두 결과 중 어느 것도 서명을 불신할 이유가 아니며, 둘 다 무엇을 받아들였는지 적어 둘 이유입니다.

권한과 제거 방법을 기록하라

아카이브 소유자, 지원되는 운영 체제 릴리스, 키 교체 경로, 제거 절차를 적으십시오. 이 네 가지 사실이 클라이언트가 은퇴하거나 공급업체가 키를 교체할 때 후임자에게 필요한 것입니다. 그것이 없으면 다음 사람은 아무 이야기 없이 소스 한 줄과 키 파일을 물려받습니다.

제거는 건너뛰기 쉬운 단계이므로 설치할 때 적어 두십시오. 소스 항목과 그 전용 키를 함께 지우고, 파일을 지우기 전에 그 키가 다른 곳에서 참조되는지 확인하십시오. 그 확인 없이 공유 키를 지우면 정리가 무관한 장애로 바뀌며, 이는 일상적인 변경에 있어 최악의 결과입니다. 그런 다음 항목이 사라진 뒤에도 일반 업데이트가 해결되는지 확인하십시오.

저장소를 제거한 뒤에도 한 가지가 남습니다. 이미 설치된 패키지는 무언가가 그것을 대체할 때까지 계속 동작하며, 정직한 질문은 어떤 권한을 추가했는지, 그리고 그 역할이 얼마나 좁게 표현되었는지입니다.