IAM 콘솔에 액세스 키가 다섯 개 있었는데 어느 것이 쓰이는지 몰라서 하나도 못 지우고 있었다. 이름에 용도가 안 적혀 있어서 temp 라는 이름의 사용자 키가 운영에서 쓰이고 있을 수도 있었다.
Table of contents
Open Table of contents
검증 — 앞자리로 한 대조
코드에는 AWS_ACCESS_KEY_ID 라는 변수 이름만 있고 값이 없으므로 실행 중인 실제 값을 봐야 했다. 각 프로젝트 컨테이너에서 printenv 로 그 변수를 찍되 cut -c1-8 로 앞자리만 잘라서 받았다.
앞자리 몇 글자만으로도 어느 키인지가 갈리므로 값 전체를 볼 필요가 없었다. 자격 값을 다루는 조사에서는 판별에 필요한 최소한만 꺼내는 것이 원칙이다.
원인 — 사용 기록이 뒤집은 이름
AWS 공식 문서대로 get-access-key-last-used 가 키의 마지막 사용 시각과 서비스를 돌려주므로 그것도 함께 봤다. 확인해 보니 temp 키가 바로 그 시점에도 계속 쓰이고 있었다.
이름만 보고 그것을 지웠으면 그 키를 쓰는 서비스가 그대로 멈췄을 것이다. 이름과 실제가 다르다는 것을 사용 기록이 알려 줬고 정리한 표에서 쓰는 곳이 없는 키 둘을 찾아냈다.
조치 — 막아 보니 드러난 실패
쓰는 곳이 없어 보이는 키는 두 가지 방법이 있었는데 바로 delete-access-key 하는 것과 update-access-key --status Inactive 로 막고 하루 지켜보는 것이다. 뒤쪽을 골랐다. 이유는 비활성화는 언제든 되돌릴 수 있지만 삭제는 되돌릴 수 없어서다. 대신 정리가 하루씩 늦어지는 것을 감수했다.
1년 넘게 사용 기록이 없던 키를 막았더니 다음 날 연락이 왔는데 월 1회 도는 배치가 그 키를 쓰고 있었다. 사용 기록이 오래된 것은 안 쓰여서가 아니라 그 배치가 계속 실패하고 있었기 때문이었고 실패를 아무도 안 보고 있었다.
주의 — 이름 규칙과 등록
앞으로 같은 조사를 반복하지 않도록 prod-orders-s3 처럼 환경과 프로젝트와 용도를 잇는 이름 규칙을 정했다. 새로 만드는 것부터 그 규칙을 지키고 옛 것은 이름을 바꿀 수 있는 것만 바꿨다.
만들 때 KEYS.md 표에 등록하게도 했는데 만든 날과 만든 사람과 쓰는 곳과 용도와 폐기 예정일을 적는다. 시험용으로 만드는 키에는 폐기 예정일을 반드시 적어 그날 확인하게 했다.
배경 — 권한과 교체 절차
권한도 확인하니 전부 AdministratorAccess 였고 조회만 하는 키가 s3:DeleteObject 까지 갖고 있었다. 권한을 용도에 맞게 좁히니 그 키가 새더라도 할 수 있는 일이 크게 줄어든다.
키가 샜을 때를 대비한 교체 절차도 만들었는데 새 키를 발급하고 배포한 뒤 새 키가 쓰이는 것을 확인하고 옛 키를 비활성화해 하루 지켜본 다음 삭제하는 순서다. 옛 키와 새 키를 같이 살려 두는 기간이 있어야 배포 사이에 서비스가 안 멈춘다. 이 절차를 만들고 한 번 연습해 뒀더니 실제 상황이 왔을 때 30분 만에 끝났다.
정리
- 외부 서비스 키는 이름만으로 용도를 모른다
- 값의 앞자리만 뽑아 어디서 쓰는지 대조한다
- 콘솔의 마지막 사용 시각도 함께 본다
- 이름과 실제가 다를 수 있다
- 지우기 전에 막아 보면 실패하고 있던 것이 드러난다
- 이름 규칙을 정하고 만들 때 기록한다
- 시험용에는 폐기 예정일을 적는다
- 권한을 용도에 맞게 좁히면 새더라도 피해가 준다