TTESays

키의 유효기간을 넘어, 자격 증명의 체류 시간을 줄여야 한다

Donghwi Shin, Jin Kwak

Published: 08:30, 11 May 2026 (Updated: 19:41, 11 May 2026)

💡

Editor Pick
- 국내, 암호키의 생명주기와 유효기간 언급
- 해외, 장기 자격 증명 자체를 줄이는 방향으로 고민/이동 중
- “키를 언제 교체할 것인가?”에서 “이 키가 꼭 오래 살아 있어야 하는가?”로 바꾸어야...

Argemma Blog의 “You don’t want long-lived keys” 에서는 Long-lived key는 시간이 지날수록 위험이 누적되는 부채이며, 가능한 한 단기·임시 키(Ephemeral key) 기반 구조로 전환해야 한다고 설명한다. 이를 위해 임시 키를 사용하는 시스템에서는 사용 기한이 만료된 키의 갱신 및 교체 등이 이 별도의 프로젝트나 긴급 작업이 아닌 시스템의 기본 동작이 되야 한다고 언급하고 있습니다. 다시 말해, 키 갱신은 나중에 해야 할 운영 상의 작업이 아닌 처음부터 설계에 포함된 기능이 되야 한다 것이다. 이와 같은 부분을 보면서 우리나라는 어떤 관점으로 주요 정보를 관리하고 사용할 것을 바라보고 있는지? 다른 국가들에서는 어떤 관점으로 바라보고 있는지 살펴보고자 한다.

키에도 수명이 있다는 말은 이미 오래된 전제

암호키는 영원히 안전한 물건이 아니다. 키는 생성되고, 사용되고, 보관되고, 폐기된다. 일정한 기간이 지나면 교체해야 하며, 사용량과 목적에 따라 유효기간도 달라진다. 이 전제는 새롭지 않다. 한국인터넷진흥원(KISA)의 「암호 키 관리 안내서」도 암호 키 관리 시스템, 암호 키 생성, 암호 키 수명주기, 암호 키 관리, 암호 키 유효기간을 주요 내용으로 제시한다. 다시 말해 지침에서도 암호키를 한 번 만들어 영원히 쓰는 값으로 보지 않는다. 키에는 생명주기가 있고, 그 생명주기를 관리해야 한다는 인식은 이미 존재하는 정설이다.

키에 수명이 있다는 사실을 인정한다면, 같은 질문을 클라우드 접근 키, API 토큰, 서비스 계정 키, CI/CD 배포 토큰, SSH 개인키 같은 운영상의 자격 증명에도 던져야 한다. 이 값들은 엄밀히 따지자면 암호키와 항상 같은 의미를 가지는 것은 아니다. 어떤 값은 암호화나 서명에 쓰이고, 어떤 값은 시스템이 특정 사용자나 서비스를 신뢰하도록 만드는 인증 정보로 쓰인다. 그러나 둘은 중요한 공통점을 가진다. 모두 시스템 안에서 권한을 열어주는 비밀값이며, 오래 남아 있을수록 유출과 오남용의 가능성이 증가한다는 것이다.

그리고 키의 유효기간을 규정 등에 적어두고 따르는 것과, 실제 시스템 안에서 오래 살아남는 비밀값을 줄이는 것은 서로 다른 문제다. 전자는 관리 절차에 가깝고, 후자는 아키텍처와 운영의 문제다. 이 차이가 이번 글의 출발점이다. 국내 지침 및 가이드들이 암호키의 생명주기와 유효기간을 말해왔다면, 해외 클라우드와 DevOps 보안 문서는 이 논리를 운영 환경의 자격 증명 관리로 확장한다. 그들은 단지 “키를 주기적으로 바꾸라”고 말하지 않는다. 더 근본적으로 묻는다. 오래 살아 있는 비밀값을 왜 계속 저장하고 배포해야 하는가.

암호키와 자격 증명은 다르지만, 같은 위험 공유

이 글에서 먼저 구분해야 할 단어가 있다. 암호키(Key)와 자격 증명(Credential)은 비슷한 맥락에서 쓰이지만 같은 개념은 아니다. 암호키는 데이터를 암호화하거나 복호화하고, 메시지나 토큰에 서명하고, 암호학적 무결성을 검증하는 데 쓰이는 값이다. 데이터 암호화 키, 서명 키, TLS 개인키 등이 이에 해당한다. 암호키의 핵심 질문은 “이 키가 암호학적으로 얼마나 안전한가”, “얼마나 오래 사용해도 되는가”, “어떤 데이터와 어떤 용도에 묶여 있는가”이다.

반면 자격 증명은 시스템이 어떤 사용자, 서비스, 장치, 자동화 작업을 신뢰하도록 만드는 인증 정보다. AWS access key, Google Cloud service account key, GitHub secret, PyPI token, SSH private key, API token 등이 여기에 포함된다. 자격 증명의 핵심 질문은 “이 값으로 무엇에 접근할 수 있는가”, “누가 이 값을 사용할 수 있는가”, “언제까지 유효한가”이다.

물론 두 개념은 실제 환경에서 겹친다. 예를 들어 SSH Private Key는 암호학적 키이면서 동시에 서버 접근을 가능하게 하는 자격 증명이다. Google Cloud Service Account Key도 암호학적으로 서명에 쓰일 수 있지만, 운영 관점에서는 특정 서비스 계정의 권한을 행사하게 만드는 자격 증명이다. 따라서 이 둘을 완전히 분리해 설명하면 현실과 멀어진다. 반대로 아무 구분 없이 “키”라고만 부르면 문제가 흐려진다.

이 글에서 다루는 핵심은 두 개념의 공통분모다. 암호키든 자격 증명이든, 시스템 안에서 권한과 신뢰를 열어주는 비밀값이 오래 살아남으면 위험은 누적된다는 것이다. 시간이 지날 수록 누가 알고 있는지 모르고, 어디에 복사되었는지 추적하기 어려우며, 어떤 서비스가 그 값에 의존하는지 파악하기 힘들어진다. 따라서 이 글에서 다루고자 하는 문제의 본질은 특정 단어 하나가 아닌 오래 살아 있는 비밀값(Long-Lived Secret)이 조직 안에 쌓이는 구조에 대한 것이다.

국내 지침은 암호키의 생명주기를 해외 지침은 자격 증명의 체류 시간을

국내 지침과 해외 지침의 차이를 “있다”와 “없다”로 나누면 부정확하다. 우리나라에도 암호키 생명주기와 유효기간을 다루는 지침 또는 가이드라인들이 있다. 따라서 “우리나라에 키 수명 개념이 부족하다”고 언급할 수 없다. 보다 정확한 차이는 적용 대상과 운영 관점에 있다. 국내 자침 및 가이드라인에서는 주로 암호키를 어떻게 생성하고, 보관하고, 사용하고, 폐기할 것인가를 다룬다. 특히 데이터 암호화, 전자서명, 암호모듈, 개인정보 보호 체계에서는 키 관리 절차가 기본이다.

그러나 클라우드와 DevOps 환경에서는 질문들과 규정만으로 충분하지 않다. 오늘날의 시스템은 암호키만으로 움직이지 않는다. 애플리케이션은 API 토큰으로 외부 서비스를 호출하고, CI/CD 파이프라인은 배포 토큰으로 패키지를 배포하며, GitHub Actions는 클라우드 리소스에 접근하고, 서비스 계정은 다른 서비스의 권한을 위임받는다. 이때 어느 공간에 장기간 저장된 비밀값에 대해 문제가 되는 것은 전통적 의미의 암호키만이 아니다. 시스템 곳곳에 저장된 장기 자격 증명 또는 Shadow 자격 증명(ex. 개인 Password Manager에 남은 자격 증명, 오래된 GitHub Secret, 더 이상 담당자가 없는 스크립트의 변수) 역시 대단히 중요한 정보로 키와 동일한 수준으로 다루어야 한다.

해외 클라우드 서비스 제공자들의 가이드라인은 이런 것들을 고려하고 있다. AWS가 말하는 Temporary security credentials, Google Cloud가 말하는 Short-lived service account credentials, GitHub Actions의 OIDC 기반 Short-lived access token은 모두 같은 방향을 가리킨다. 오래 보관하는 자격 증명을 줄이고, 필요한 순간에 짧은 수명으로 발급받도록 만들자는 것이다. 이는 Just-in-Time의 컨셉을 반영하는 것으로 현재 중요하게 바라보고 있는 Zero Trust와 방향성을 같이 하는 것이다. 이와 같은 변화는 “암호키 유효기간을 관리하라”는 말보다 한 단계 더 운영적이다. 비밀값을 잘 보관하는 문제를 넘어, 비밀값이 시스템 안에 오래 머무르지 않게 만드는 설계의 문제로 이동한다.

❗

You do not have to distribute or embed long-term AWS security credentials with an application. After temporary security credentials expire, they cannot be reused.
from "Temporary security credentials in IAM"

이 차이는 작지만 중요하다. 국내 지침 및 가이드라인에서 “암호키/중요 정보에 수명이 있으니 그 수명을 고려하여 관리해야 한다.”고 말한다면, 해외 지침들에서는 “권한을 행사하는 자격 증명이 오래 살아남지 않게 해야 한다”고 말한다. 핵심은 유효기간이라는 문서상의 기준이 아니라, 비밀값이 실제 시스템 안에 머무는 시간이다.

💡

“The most secure way to authenticate as a service account is to obtain short-lived credentials for the service account in the form of an OAuth 2.0 access token.By default, these tokens expire after 1 hour. They also create less risk than long-lived credentials, such as service account keys.”
from "Google Cloud IAM, Service account credentials"

교체/갱신은 필요하지만, 이것만으로는 부족하다

암호키, 자격 증명의 주기적인 교체 모두 보안에서 중요한 절차다. 오래된 키를 계속 사용하는 조직은 위험하며, 오래된 토큰이나 Access Key를 계속 유지하는 조직 역시 위험하다. 그러나 교체가 유일한 해법처럼 제시될 때, 우리는 더 근본적인 문제를 놓칠 수 있다. 교체해야 할 장기 비밀값이 너무 많다는 사실 자체가 이미 위험이기 때문이다.

장기 자격 증명은 대부분 처음부터 나쁜 의도로 만들어지지 않는다. 개발자는 배포를 자동화하기 위해 토큰을 만든다. 운영자는 원활한 시스템 운영을 위해 SSH 키를 둔다. 팀은 빠른 출시를 위해 클라우드 Access key를 CI/CD 환경변수에 저장한다. 이 모든 결정은 그 순간에는 합리적으로 보인다. 그러나 시간이 지나면 이 값들은 조직의 기억 밖으로 밀려나 Shadow Secret로 남는다.

이 상태에서 교체라는 Task는 고통스럽다. 값을 바꾸는 순간 어디서 무엇이 깨질지 알 수 없기 때문이다. 어떤 서비스가 교체한 자격 증명을 쓰는지, 어떤 파이프라인이 그 토큰에 의존하는지, 어떤 배치 작업이 오래된 Access Key를 참조하는지 확인해야 한다. 문서가 오래되었거나 소유자가 사라졌다면 교체는 보안 절차가 아닌 장애 가능성을 시험하는 일이 된다.

해외 지침 및 가이드가 제시하는 방향은 단순히 사용 주기를 더 짧게 만들라는 것이 아니다. 장기간 사용되는 자격 증명 자체를 줄이라는 것이다. 결국 발급된 자격 증명이 어딘가에 저장되는 방식이 아닌 필요한 순간에 발급하고 작업이 끝나면 의미를 상실하도록 만들어야 한다는 것이다. 이러한 방향성을 갖고 있다면 교체라는 Task가 별도 이벤트가 아닌 시스템의 기본 동작에 가까워져야 한다.

최소권한 다음에는 최소시간이 필요하다

보안에서 최소권한 원칙(Least Privilege)은 익숙하다. 사용자는 필요한 권한만 갖고, 서비스는 수행 작업에 필요한 범위 안에서 권한을 행사한다. 이 원칙은 암호키와 자격 증명 모두에 적용된다. 암호키는 특정 데이터, 특정 용도, 특정 시스템에 한정되어야 하고, 자격 증명은 특정 사용자, 특정 작업, 특정 리소스 접근으로 제한되어야 한다.

그러나 Long-lived Secret 문제를 다룰 때는 여기에 하나의 축을 더해야 한다. 권한의 범위뿐 아니라 권한의 지속 시간도 줄여야 한다. 같은 권한이라도 1년 동안 살아 있는 Access Credential과 1시간 뒤 만료되는 Access Credential은 전혀 다른 위험 요소가 되는 것이다. 두 가지 상황에 서로 같은 리소스에 접근할 수 있더라도, 공격자가 그것을 탈취했을 때 사용할 수 있는 시간이 다르다. 전자는 유출 사실을 조직이 인지할 때까지 계속 악용될 수 있고, 후자는 만료 시점 이후에 가치가 급격히 떨어진다.

물론 Short-lived Secret이 모든 공격을 막을수는 없다. 공격자가 토큰이 살아 있는 동안 악용할 수도 있다. 또한 모든 암호키를 짧은 수명의 Credential처럼 다룰 수도 없다. 데이터 암호화 키나 서명 키처럼 장기간 유지해야 하는 키도 존재한다. 그러나 이 차이가 오히려 핵심이다. 오래 유지해야 하는 키는 더 엄격하게 보호하고, 오래 유지할 필요가 없는 자격 증명은 짧은 시간 사용되고 바뀌도록 해야 한다. 모든 비밀값을 같은 방식으로 관리하는 것이 아닌 성격에 따라 다르게 관리해야 한다는 의미이다.

이 관점에서 Short-lived Credential은 최소권한 원칙의 시간 버전이라고 볼 수 있다. 최소권한이 “무엇을 할 수 있는가”를 제한한다면, 최소시간은 “얼마나 오래 할 수 있는가”를 제한한다. 클라우드와 자동화 환경에서 이 두 원칙은 함께 작동해야 한다. 권한이 적어도 오래 살아 있으면 위험하고, 시간이 짧아도 권한이 너무 크면 위험하다. 그래서 앞으로 보안의 목표는 '좁은 권한과 짧은 수명'을 함께 설계하는 것 그리고 이러한 속성을 기본 동작으로 설정하는 것이라 할 수 있다.

“키를 언제 교체할 것인가”에서 멈출 수 없음

국내 보안 관련 지침 또는 가이드라인에서 암호키의 생명주기와 유효기간을 말해온 것은 중요하다. 그것은 키가 관리되어야 할 대상이라는 기본 전제를 만든 것이다. 그러나 이제 그 논리는 클라우드와 DevOps 환경의 Credential 관리로 확장되어야 한다. 그리고 질문이 “암호키를 언제 교체할 것인가?”에서 멈추면 안 된다. “이 자격 증명이 꼭 오래 살아 있어야 하는가?”로 나아가야 한다.

예를 들어 배포 파이프라인이 클라우드에 접근해야 한다면, 장기 Access Key를 GitHub Secret에 저장하는 방식이 유일한 선택인지 되물어야 한다. 서비스가 다른 서비스의 권한을 사용해야 한다면, Long-lived Access Key를 파일로 배포해야 하는지 검토해야 한다. 서버에 접근해야 한다면, 오래된 SSH Private Key를 여러 사람이 복사해 쓰는 구조가 필요한지 살펴야 한다. 패키지를 배포해야 한다면, 정적 토큰을 여러 파이프라인에 재사용하는 대신 Trusted Publisher나 OIDC 기반 발급 구조를 검토해야 한다.

이 변화는 보안팀만의 일이 아니다. 개발팀, 플랫폼팀, 클라우드 운영팀, DevOps 팀이 함께 다뤄야 할 설계와 구조의 문제이다. Long-lived Credential은 대개 편의를 위해 만들어지지만, 시간이 지나면 조직 전체의 공격 표면이 된다. 반대로 Short-lived Credential은 처음에는 설정이 번거로울 수 있지만, 장기적으로는 교체/갱신과 폐기, 유출 대응의 부담을 줄인다. 결국 문단 초기에 언급했던 '부채'라는 부분을 줄일 수 있는 효과를 가져온다.

비밀을 지키는 일에서 비밀이 오래 남지 않게 만드는 일

암호키의 생명주기와 유효기간을 관리하는 일은 여전히 중요하다. 그러나 그것만으로는 충분하지 않다. 현대 시스템에서 위험은 암호키 자체에만 있지 않다. 위험은 오래 살아 있는 자격 증명이 조직 곳곳에 남아 있고, 그 존재를 누구도 정확히 알지 못하는 상태에서 커진다.

이 글에서 제시하고자 하는 핵심은 암호키와 자격 증명 두 가지 값 모두 비밀값이며, 오래 살아남으면 위험해진다는 것을 살펴보자는 것이다. 그래서 우리는 두 개념을 구분해서 관리하되, 오래 살아 있는 비밀값을 줄여야 한다는 공통 원칙 아래 함께 바라보자는 것이다.

국내 각종 자료에서 암호키에 수명이 있다는 사실을 언급하고 있다. 이제 필요한 것은 그 논리를 한 단계 더 명확하게 구체화하는 일이다. 키에 수명이 있다면, 자격 증명에도 수명이 있어야 한다. 특히 클라우드와 DevOps 환경의 자격 증명은 가능한 한 짧게 살아야 한다. 보안의 기준은 “얼마나 잘 보관했는가”에서 “얼마나 오래 남겨두지 않았는가”로 이동하고 있다는 것을 이해해야 한다. 그리고 암호키에도 이와 같은 사상을 적용할 수 있는지 생각하고 운영의 방식을 고민해야 한다는 것이다.

우리에게 다음 질문은 분명해야 한다. 우리는 암호키를 얼마나 자주 교체하고 있는가만 물어서는 안 된다. 오래 살아 있는 자격 증명을 얼마나 줄이고 관리하고 있는가, 그리고 꼭 오래 유지해야 하는 암호키를 얼마나 집중적으로 보호하고 있는가를 함께 물어야 한다. 보안은 더 강한 금고를 만드는 일이기도 하지만, 훔칠 수 있는 오래된 열쇠를 남겨두지 않는 일이기도 하다.

You don’t want long-lived keys — Argemma, 2026
Temporary security credentials in IAM — AWS, Documentation
AWS security credentials — AWS, Documentation
Security best practices in IAM — AWS, Documentation
Service account credentials — Google Cloud, Documentation
Create short-lived credentials for a service account — Google Cloud, Documentation
Introducing time-bound key authentication for service accounts — Google Cloud Blog, 2023
OpenID Connect — GitHub Docs
Configuring OpenID Connect in cloud providers — GitHub Docs
암호 키 관리 안내서 — KISA 암호이용활성화, 2014
암호 알고리즘 및 키 길이 이용 안내서 — KISA 암호이용활성화, 2018

[Claude Mythos 이후 #3] Claude Mythos 시대의 위험수용: 수용된 취약점은 사라진 위험이 아니다

[Claude Mythos 이후 #2] Claude Mythos가 드러낸 보안 부채: 발견된 취약점은 왜 닫히지 않는가

[Hackyboiz 해킹짹짹 x TTE] 하늘을 향한 전쟁은 이미 시작되었다.

[Claude Mythos 이후 #1] Claude Mythos 이후, 보안은 취약점을 찾는 기술이 아닌 감당하는 시스템