장기 수명 키가 시간이 지날수록 왜 더 큰 부담이 되는지, 단기 수명 키로 전환하면 어떤 운영·보안 이점을 얻을 수 있는지 설명합니다.
Kelby Ludwig보안 엔지니어
2026년 4월 20일
장기 수명 키는 대체로 시간이 지날수록 위험이 누적되는 부담입니다:
이 위험은 두 가지 방식으로 관리할 수 있습니다. 첫 번째는 특정 키가 할 수 있는 일의 범위를 줄이는 것입니다. 이것이 이상적이지만 항상 가능한 것은 아닙니다. 어떤 키는 자기 역할을 수행하려면 본질적으로 강력해야 할 수도 있습니다. 더 일반적인 위험 감소 방법은 키를 회전하는 것입니다. 그리고 키 회전은 엄청나게 성가신 일입니다. 많은 독자들이 아마 다음과 같은 경험을 해봤을 것이라고 생각합니다:
임시 키를 중심으로 구축된 시스템(즉, 대략 1일 이하만 유효한 키)은 “회전”이 내장 기능이기 때문에 이런 고통의 상당 부분을 피해 갑니다. 제 생각에 장기 수명 키를 임시 키로 대체하는 것은 보안 엔지니어링 노력을 가장 가치 있게 쓰는 방법 중 하나입니다. 몇 가지 구체적인 예를 들면 다음과 같습니다:
장기 수명 프로덕션 SSH 키는 여기저기 복사되고, 설정 파일에 하드코딩되며, 사고가 발생할 때까지 잊혀질 수도 있습니다. 장기 수명 SSH 키를 EC2 instance connect 같은 패턴으로 대체하면, SSH 키는 최근의 인증 및 권한 부여 확인을 요구하는 임시 자격 증명이 됩니다.
어떻게 들어갔는지는 모르겠지만 CTO의 개인 1Password에 들어가 있고, 덜 우연하게도 품질이 제각각인 여러 릴리스 파이프라인에서 재사용된 정적 PyPI 토큰에 의존하는 대신, trusted publishers를 사용할 수 있습니다. 이렇게 하면 특정 GitHub Actions 워크플로(아마 이미 릴리스에 사용하고 있을 수도 있습니다)를 사용해 패키지 릴리스를 위한 임시 자격 증명을 생성할 수 있습니다. 그 정적 PyPI 토큰을 폐기하러 갈 때, 방금 망가뜨리기 전까지는 잊고 있었던 일회성 릴리스 파이프라인 어딘가에도 그 토큰이 들어가 있었다는 사실을 발견할지도 모릅니다.
SSO가 유용한 큰 이유 중 하나는 각 애플리케이션에서 사용자가 선택한 장기 수명 비밀번호를 신뢰할 수 있는 identity provider (IdP)가 발급한 단기 수명 인증 어설션으로 대체할 수 있기 때문입니다. 공격자는 부실하게 선택된 비밀번호는 추측할 수 있습니다. 하지만 서명된 XML 문서를 같은 방식으로 추측할 수는 없습니다.2
당신 안의 보안 덕후는 짜증이 날지도 모릅니다. 정말로 모든 장기 수명 키를 없애는 것이 그럴듯한 이야기일까요? 위의 SSO 예시는 각 인증 어설션은 임시적이지만, 그 어설션에 서명한 키는 그렇지 않다는 사실을 대충 넘어가고 있습니다.
맞습니다. 모든 장기 수명 키를 하나도 남김없이 없애지는 못할 수도 있습니다. 하지만 그렇더라도 장기 수명 키의 수를 줄이는 데에는 여전히 상당한 이점이 있습니다.
첫째, 장기 수명 키의 수를 줄이면 보안 노력을 집중할 수 있습니다. 예를 들어, 임의의 엔지니어 노트북의 보안을 따져 보는 것보다 오직 KMS에 무언가에 서명하라고 지시하기 위해서만 존재하는 EC2 인스턴스의 보안을 따져 보는 편이 훨씬 쉽습니다. 장기 수명 키의 수를 줄이면, 더 강화하기 쉽고 이해하기 쉬운 더 작고 더 집중된 인프라 조각들을 만드는 경우도 많습니다.
또 다른 장점은 보안에 민감한 인프라는 대부분의 도구보다 더 높은 수준의 엄밀함을 요구하는 경향이 있다는 점입니다. 엄밀하다는 것은 종종 속도를 조금 늦춘다는 뜻입니다. 항상 엄밀함이 필요한 것은 아닙니다. 또한 어디에서 속도를 희생할지 신중해야 합니다. 앞서 언급한 암호화 키 한계 말입니다. 그런 문제가 임의의 엔지니어링 팀에게는 부차적인 관심사가 되어 기능 작업 시간을 잡아먹게 하고 싶지는 않을 것입니다. 그런 일은 잊히거나, 우선순위에서 밀리거나, 잘못 처리될 가능성이 더 큽니다. 대신 그것을 누군가(또는 어떤 그룹)의 핵심 관심사로 만들고, 다른 모든 사람을 위해 한 번만 해결할 수 있습니다.
장기 키를 제대로 유지 관리하려면 일이 많이 듭니다. 장기 수명 키에 대해 제가 일반적으로 드리는 조언은 대략 다음과 같습니다:
특정 키나 자격 증명이 할 수 있는 일의 범위를 제한하세요. 예를 들어, 데이터 암호화 키를 고객 데이터의 특정 샤드로 한정하고 싶을 수 있습니다.
특정 키의 최대 수명 한계를 논리적으로 따져 보세요. 암호화 키의 전형적인 보안 모델은 대략 “슈퍼컴퓨터로도 키를 추측하는 데 수십억 년이 걸린다” 같은 것입니다. 여러분이 정하는 한계도 비슷하게 강하고 자신 있게 말할 수 있는 주장 위에 있어야 합니다.
장기 수명 키는 적어도 분기마다 회전하는 것을 목표로 하세요. 운영 관점에서 키를 회전하는 것은 근육을 단련하는 것과 비슷합니다. 정기적으로 하면 더 정확하고 유용한 도구나 문서를 갖추게 될 가능성이 높습니다. 좋은 도구와 문서는 근육을 삐끗하는 SLA를 놓칠 가능성을 줄여 줍니다.
이 설정은 인정하건대, 고된 잡일입니다. 그 잡일을 모두에게 분산시키지 마세요. 그 노력은 엄밀함을 갖추도록 동기 부여된 동시에 모두를 위해 한 번만 해결할 수 있는 그룹에 집중할 수 있습니다. 잡일을 줄이고 엄밀함을 통합하는 것은 견고한 보안 인프라의 큰 장점입니다.
예를 들어, 같은 AES-GCM 키로 2^32개보다 많은 메시지를 암호화하면 메시지 위조 공격의 위험이 생기기 시작합니다.↩︎
다만 지금은 SAML이 악몽 같은 프로토콜이라는 점은 잠시 제쳐 둡시다
Argemma는 실무 중심의 보안 및 엔지니어링 전문성을 바탕으로 기술 스타트업을 지원하는 보안 엔지니어링 컨설팅 회사입니다. 저희는 엔지니어링 및 프로덕트 팀과 직접 협업하여 설계를 검토하고, 영향이 큰 결함을 발견하며, 실행 가능한 보안 가이드를 제공할 수 있습니다.
흥미로운 소프트웨어를 만들고 있고 제품의 보안에 대한 확신을 높이고 싶다면, 이 도메인의 hello@로 연락해 주세요.
