인증서 만료 사고가 반복되는 이유
이 글의 순서 4개 절
에릭슨은 2018년 12월 장비 소프트웨어의 인증서 만료로 영국 O2의 4G를 하루 가까이, 일본 소프트뱅크를 4시간 넘게 세웠다. 마이크로소프트 Teams는 2020년 2월, 스포티파이는 2020년 8월에 같은 이유로 죽었다. 이 회사들이 인증서를 몰라서 생긴 일은 아니다. 만료 사고는 조직이 일하는 구조에서 나고, 기술력만으로는 끊기지 않는다.
성공하면 잊히는 일
인증서 갱신은 성공하면 아무 일도 일어나지 않는다. 잘한 사람은 보상이 없고, 잊은 사람에게만 청구서가 온다. 이런 작업을 사람의 주의력에 맡기면 결국 잊힌다. 1년에 한 번, 90일에 한 번 오는 일을 기억하는 건 사람 몫이 아니다.
달력에 적어 두는 것도 해결이 못 된다. 적은 사람은 퇴사하고, 알림이 울린 날은 하필 장애 대응 중이고, 메일함 규칙이 알림을 접어 넣는다. 개인의 기억을 시스템으로 바꾸지 않는 한 사고는 확률 문제로 남는다.
사람이 기억해야 할 일은 0으로 줄인다. 갱신은 자동화하고, 사람에게는 예외만 넘긴다.
누구 담당인가
만료 사고 뒤에 회고를 하면 빠지지 않는 말이 있다. “그건 저희 담당이 아닌 줄 알았어요.” 인증서 한 장에도 손이 여럿 닿는다.
- 인증서를 발급한 사람 (보안팀이나 그때 그 개발자)
- 인증서가 설치된 서버를 관리하는 사람 (인프라팀)
- 그 서버 위 서비스의 담당자 (개발팀)
- 도메인을 관리하는 사람 (총무팀일 때도 있다)
넷 다 “내 것”이라고 생각하지 않는 자산이 인증서다. 발급한 사람이 퇴사하면 그 인증서는 고아가 된다. 갱신 알림 메일이 퇴사자 메일함으로 가는 것이 만료 사고의 가장 고전적인 시나리오다.
알림 수신처는 사람 대신 팀 주소나 채널로 두고, 인증서마다 소유 팀을 적어 둔다. 다들 사고가 나고 나서야 배우는 것들이다.
목록 밖의 인증서
“우리 인증서 전부 몇 장이에요?“에 바로 답할 수 있는 조직은 드물다. 웹서버 인증서는 알아도 이런 것들은 목록 밖에 있다.
- 로드밸런서에 직접 올린 것
- 개발자가 테스트하다 그대로 운영에 들어간 것
- 장비 관리 페이지, 내부 API, VPN, 메일 서버의 것
- 협력사가 발급해 넣어 준 것
목록에 없는 인증서는 만료 감시도 없다. 사고는 늘 목록 밖에서 난다. 목록 안의 것은 어쨌든 누군가 보고 있기 때문이다.
인벤토리를 손으로 만들면 만든 날부터 낡는다. 스캔으로 만들고, 새 도메인이나 새 서비스가 생기면 자동으로 들어가게 해야 유지된다. 목록 밖도 정기적으로 뒤진다. 공개 서비스라면 CT 로그가 좋은 출발점이다. 조직 도메인으로 발급된 인증서는 어차피 전부 공개 기록에 남는다.
자동갱신을 걸어 뒀다면
“저희는 certbot 자동갱신 해요”는 절반만 안심되는 말이다. 자동갱신은 조용히 죽는다. 타이머가 꺼지고, 챌린지 경로가 막히고, DNS 토큰이 만료된다. 자동화가 실패했다는 사실을 자동화가 스스로 알려 주지는 않는다.
그래서 감시는 갱신 시스템과 떼어 둔다. 갱신하는 시스템에 감시까지 맡기면 그 시스템이 죽을 때 둘 다 죽는다. 감시는 바깥에서, 실제로 서빙되는 인증서를, 갱신 주기보다 촘촘하게 봐야 한다.
알람은 만료일이 아니라 “정상이라면 이미 갱신됐어야 하는 시점”에 맞춘다. 만료 30일 전인데 아직 옛 인증서라면 그때 울려야 한다. 만료 3일 전에야 울리면 주말이 끼는 순간 끝이다.
조직이 가장 자주 빼먹는 것이 이 감시 층이다. 갱신 자동화는 다들 하는데, 그 자동화를 감시하는 일은 첫 사고가 날 때까지 “언젠가”로 밀린다.
당장은 도메인 하나를 진단 툴에 넣어 보는 것으로 충분하다. 지금 30일 안에 만료되는 인증서가 몇 장인지조차 모른다면 기억, 담당, 목록 쪽이 이미 무너져 있다는 신호다. 여러 도메인을 계속 봐야 한다면 만료 감시 구독에 넣어 두면 된다. 5개까지 무료로 매일 확인한다.