TT Lab
블로그 시작하기
배우기 러닝패스 코스

서버를 처음부터 잠근다

빠른 패치와 안전한 패치

TT Lab 에서 이어서 보기

한 줄 요약

패치가 늦은 서버는 이미 공개된 취약점에 그대로 노출됩니다. 보안 갱신은 자동으로 빠르게, 기능 갱신은 사람이 판단해 받는 것이 균형점입니다. unattended-upgrades 가 이 경계를 설정으로 정합니다.

왜 이게 필요했나

취약점이 공개되면 그것을 노리는 도구가 며칠 안에 돕니다. 손으로 갱신하는 서버는 그 창이 몇 주로 늘어나고, 서버가 여러 대면 어떤 건 됐고 어떤 건 안 됐는지 아무도 기억하지 못합니다. 그렇다고 모든 갱신을 자동으로 받으면, 기능 변경이 서비스를 깨뜨려 "자동 갱신 때문에 장애가 났다" 가 되고, 그러면 자동 갱신 자체를 꺼 버립니다.

어떻게 동작하나

데비안·우분투 저장소는 패키지를 묶음(Suite)으로 나눕니다 — 보안 갱신(-security)과 일반 갱신(-updates)이 다른 묶음입니다. unattended-upgrades 의 Origins-Pattern 이 어느 묶음을 자동으로 받을지 정합니다. 보안 묶음만 적으면 보안 패치만 자동으로 적용되고, 기능 갱신은 사람이 판단할 때까지 기다립니다.

재부팅도 통제합니다. 커널 갱신처럼 재부팅이 필요한 경우 Automatic-Reboot "true" 와 Automatic-Reboot-Time "02:00" 으로 정해진 시각에만 재부팅하게 합니다. 아무 때나 재부팅하면 서비스가 끊기기 때문입니다.

자동 실행은 두 곳이 함께 켜져야 합니다. apt-daily-upgrade.timer 가 주기적으로 깨우고, /etc/apt/apt.conf.d/20auto-upgrades 의 Unattended-Upgrade "1" 이 실제로 갱신을 돌립니다. 둘 중 하나라도 0이면 타이머가 돌아도 아무 일이 없습니다.

마지막으로 확인 가능성입니다. 자동 갱신의 진짜 가치는 "됐는지 볼 수 있다" 에 있습니다. /var/log/unattended-upgrades/ 에 무엇이 언제 적용됐는지 남습니다. 로그가 없으면 자동으로 됐는지 조용히 실패했는지 구별할 수 없습니다.

현장에서 만나는 모습

가장 흔한 실수는 Origins-Pattern 을 너무 넓게 두어 기능 갱신까지 받는 것입니다. 그러면 깨지는 변경이 새벽에 조용히 들어와 아침에 장애를 발견합니다. 둘째는 타이머만 켜고 20auto-upgrades 를 0으로 둔 경우로, 설정은 있는데 아무것도 안 하는 상태입니다. 셋째는 재부팅 시각을 정하지 않아 업무 시간에 서버가 재부팅되는 것입니다.

English corner

다음 실습에서 할 것

보안 갱신만 자동으로 받도록 unattended-upgrades 를 설정하고, 기능 갱신은 남기고, 재부팅은 정해진 시각으로 정하고, 무엇이 적용됐는지 로그로 확인합니다.

한 걸음 더 — 스테이징과 커널 갱신

보안 갱신을 자동으로 받더라도, 서버가 수백 대면 한꺼번에 받는 것이 위험할 수 있습니다. 갱신 하나가 드물게 서비스를 깨뜨리면 전부가 동시에 깨집니다. 그래서 작은 묶음(카나리)에 먼저 적용해 하루 지켜보고 나머지로 넓히거나, 사내 미러에서 갱신을 며칠 묵힌 뒤 배포하는 방식을 함께 씁니다. 자동과 통제는 반대말이 아닙니다.

커널 갱신은 특별합니다. 재부팅해야 적용되고, 그때까지 옛 커널로 돕니다. needrestart 나 /var/run/reboot-required 로 '재부팅이 밀려 있다' 를 감지해, 정해진 유지보수 시간에만 재부팅하게 합니다. 재부팅을 영원히 미루면 커널 취약점은 패치를 받아 놓고도 적용되지 않은 채 남습니다.

점검 순서

  1. 보안 묶음만 자동 대상인가(Origins-Pattern), 기능 갱신은 사람 판단으로 남는가.
  2. 타이머와 20auto-upgrades 가 둘 다 켜져 실제로 도는가.
  3. 재부팅 시각이 유지보수 시간으로 정해졌는가.
  4. 적용 결과가 로그로 남아 '됐는지' 를 확인할 수 있는가.