문제가 되는 부분과 일반적인 해결책
일반적으로 API를 호출할 때는 API Key라는 거를 같이 넘겨야 합니다. 아무나 제한없이 API를 호출할 수 있으면 기업 입장에서는 여러 단점이 있기 때문입니다.
- 호출제한을 할 수 없음
- 디도스 (DDos) 공격의 대상이 될 수 있음
- 수익화를 하기 어려움
당장 네이버의 API 문서만 봐도 호출제한이 있고, API를 호출하기 위해서는 회원가입을 한 후 API Key를 발급 받아야 합니다.
문제는 API Key를 어떻게 관리해야 할까입니다. 호출제한 정도만 있으면 API Key가 유출돼도 귀여운 정도에서 끝나지만, 만약에 쓴 만큼 과금되는 API거나 개인정보를 많이 담고 있는 API라면 API Key가 유출되는 거 자체가 너무 큰 위험입니다! 😨
이를 위해 애플리케이션이 실행 될 때는 API Key를 환경 변수나 Program Argument로 받고 API Key 자체는 여러 Secret Manager를 사용해서 관리하는 경우가 많습니다. (Github Secrets, Vault 등)
실용적인 관점에서, 외않되?
하지만 정말 이게 최선일까요? 사실 API는 당연히 환경 변수로 관리하고 배포/개발 따로 관리하고 등을 무지성으로 지키고 있었습니다. 하지만 이런 관리는 당연하지만 공짜가 아닙니다. 아래에 이와 같이 API Key를 관리하면서 겪은 불편함을 적어 봤습니다.
- 프로젝트를 새로 시작하면 API키를 찾아서 1개 1개 넣어 줘야 한다.
- 개발/운영 환경의 API Key를 노션 등에 적어서 관리해야 한다.
- 실수로 잘못 복붙을 하면 오류가 뭔지 한참 찾아야 한다.
- API Key에 변경이 있으면 Secret Manager에 접속해서 업데이트 하고 잘 됐는지 확인해야 한다.
사소하게 보일 지도 모르지만, 쌓이면 생산성에 지장을 주긴 합니다. 여기서 의문이 들었습니다. Repo가 Private이면 왜 API Key를 그냥 Code에 넣어서 enum 같은 곳에 관리하면 안 되지? 그렇게 하면 너무 편할 거 같은데! 🤔
API Key를 하드코딩해서 관리하며 느낀 점
그래서 그렇게 했습니다. 쓰는 사람도 거의 없는 서비스니 Repo를 Private으로 돌리고 API Key를 그냥 하드코딩해서 관리했습니다. 느낀점은... 일단 겁나 편합니다.
사실 이렇게 API를 관리할까 한 것은 회사 생활 영향도 있습니다. 회사 코드 베이스를 보면서 해야 하기 때문에 해야 하는 것이 아니라, 실용적인 관점에서 생각하는 경향이 늘어났습니다. 사실 우리는 일을 하면서, 코드를 치면서 예술을 하는게 아니라 비즈니스적인 가치를 제공하는게 제1 목표가 돼야 한다고 생각하기 때문에, 이런 관점을 가지는 것도 중요합니다.
이유 1: 나중에 Private Repo를 Public Repo로 돌리면 API Key가 노출됨
그럴일이 정말 없을 거 같아도 Private Repo로 한 프로젝트를 Public Repo로 바꾸고 싶을 수 있습니다. 이 경우 그냥 하드코딩된 API Key를 지우고 commit 한 뒤에 Public Repo로 바꾸면 되지 않을까 생각 하실 수 있지만... Git에서는 과거의 모든 Commit 기록이 남습니다. 🥹 이 경우 어느 특정 시점에 하드코딩해서 관리한 적이 1번이라도 있으면 API Key가 노출됩니다.
물론 Squash를 다 때려버려도 됩니다. 하지만 하드코딩된 API Key가 있는 Commit 내역을 다 찾아내서 Squash 하고, Git을 쓰는 이유인 과거 시점으로 돌아가거나 특정 Commit을 Revert 하는 등의 장점을 포기해야 하니... 가능은 해도 혹시 Public Repo로 돌릴 가능성이 조금이라도 있다면 하드코딩해서 관리하지 않는게 정신 건강에 좋을 듯 합니다.
이유 2: 무중단으로 API Key를 바꾸기 힘들다
작고 귀여운 우리의 포트폴리오에서는 걱정할 필요가 없지만, 큰 기업의 운영 환경에서는 일반적으로 API Key가 유출될 것을 걱정해야 합니다. 그래서 상황마다 다르겠지만 짧게는 몇 시간에서 길게는 몇 달에 1번은 API Key를 교체해야 하는 경우가 있습니다.
게다가 이런 큰 기업은 모든 배포 프로세스에서 무중단을 신경써야 합니다. API Key를 코드가 아닌 솔루션으로 관리하고 있다면 Cloud Config 같은 곳에서 API Key를 변경하고 업데이트 되는 포인트를 찌르거나 하면 무중단으로 바꿀 수 있습니다. 사실은... 이건 하드코딩해도 가능합니다. API Key를 새로 발급 받고 revoke는 하지 않은 상태에서 카나리 배포를 한다면 무중단으로 충분히 가능합니다.
진짜 문제는 하드코딩 된 API Key를 바꿀 수는 있지만, 이거 또한 관리 포인트입니다. 만약 1주일에 1번 API Key를 업데이트 해야 한다면, 1주일에 1번 배포를 해야 하는데... 생각만 해도 짜증납니다. 즉, 가능은 해도 자동화를 할 수 없기 때문에 이 경우 API Key를 하드코딩하는건 굉장히 말리고 싶은 결정입니다.
참고
'👨💻 프로그래밍 > 🔒 보안' 카테고리의 다른 글
| 다양한 로그인 방법을 알아보자 (OAuth, Open ID, OIDC, SSO, SFA, 2FA, MFA, OTP, PassKey) (0) | 2024.02.08 |
|---|---|
| 망분리 (Network Segregation), 왜 필요할까? (0) | 2023.09.27 |
| 스프링 서큐리티(Spring Security) 구조 이해하기 (0) | 2023.04.11 |
