대상 OS: Debian 12 (bookworm)

서버 침해는 ‘취약점’만으로 일어나지 않습니다.
업데이트 경로가 오염되면, 공격자는 “정상 패키지 업데이트”라는 얼굴로 악성 코드를 배포할 수 있습니다.
즉, 패키지 저장소/서명키 관리는 공급망(supply chain) 보안의 핵심입니다.
그런데 많은 서버는 과거 관습대로 apt-key를 쓰거나, 키를 한 곳(trusted.gpg)에 몰아넣거나, 어떤 저장소가 어떤 키로 서명되는지 모르는 상태로 운영됩니다.

이 글은 Debian 12에서 APT 저장소/서명키를 ‘키링 분리(signed-by)’ 방식으로 정리하고, apt-key를 제거하며, pinning으로 우선순위를 통제하고, InRelease 서명 검증 상태를 점검하는 방법을 실전 기준으로 정리합니다.

---

1) 목표: “어떤 repo를 어떤 키로 믿는지”를 명확히

1)

각 저장소는 지정된 키(키링 파일)로만 서명 검증되게 만든다(signed-by)

2)

불필요한 전역 신뢰(trusted.gpg, trusted.gpg.d)를 줄인다

3)

서드파티 repo는 pinning으로 우선순위를 낮추거나 특정 패키지만 허용한다

4)

서명 검증 실패/키 만료를 조기에 발견할 점검 루틴을 만든다

---

2) 현재 상태 점검: apt-key, sources, trusted 키링

1)

apt-key 상태 확인(사용 중이라면 경고가 나올 수 있음)

sudo apt-key list 2>/dev/null | head -n 60 || true

2)

전역 신뢰 키링 확인

sudo ls -la /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d 2>/dev/null || true

3)

저장소 목록 확인

grep -R "^deb " -n /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null | sed -n '1,200p'

4)

APT가 어떤 저장소를 실제로 읽는지 확인

apt-cache policy | sed -n '1,120p'

---

3) 키링 디렉터리 표준: /usr/share/keyrings

Debian 12에서는 저장소별 키를 /usr/share/keyrings 아래에 개별 파일로 두는 패턴이 널리 쓰입니다.

1)

키링 디렉터리 확인

ls -la /usr/share/keyrings | head -n 40

---

4) 저장소를 signed-by로 묶기(핵심 패턴)

아래는 “서드파티 repo를 새로 추가”하거나 “기존 repo를 정리”할 때의 표준 패턴입니다.

1)

(예시) repo 키를 ASCII(armored)로 받은 경우 → dearmor 해서 keyring 파일 생성

curl -fsSL https://example.com/repo.gpg | gpg --dearmor | sudo tee /usr/share/keyrings/example-repo.gpg >/dev/null
sudo chmod 0644 /usr/share/keyrings/example-repo.gpg

2)

sources.list.d에 signed-by로 연결

sudo tee /etc/apt/sources.list.d/example.list >/dev/null /dev/null || true

주의
- apt-key del은 예시이며, 실제 키 ID는 환경마다 다릅니다.
- repo를 signed-by로 옮기기 전에 키를 지우면 apt update가 실패할 수 있습니다.

---

6) pinning으로 서드파티 repo 영향 최소화

서드파티 repo를 써야 한다면, “기본 우선순위”를 낮춰 Debian 공식 저장소가 우선되게 만들 수 있습니다.

1)

현재 우선순위 확인(패키지별)

apt-cache policy openssl | sed -n '1,120p'

2)

pinning 파일 생성(예시: example.com repo는 우선순위 낮게)

sudo tee /etc/apt/preferences.d/90-example-repo.pref >/dev/null