IAM 역할과 사용자, 서버에 키를 심지 않는 방법

서버에 심은 열쇠는 교체 비용으로 돌아옵니다

프로그램이 다른 서비스를 호출해야 할 때 가장 쉬운 방법은 장기 열쇠를 파일에 넣는 것입니다. 문제는 그 열쇠가 영원히 유효하다는 점입니다. 유출되면 언제든 쓸 수 있고, 어디에 몇 개를 심었는지 추적하기 어렵습니다. 역할을 붙이는 방식은 이 문제를 구조로 해결합니다. 서버에 역할을 연결하면 짧은 기간만 유효한 자격 증명이 자동으로 발급되고 자동으로 갱신됩니다. 파일에 저장할 열쇠가 없으므로 교체 작업도 사라집니다. 그래서 선택 기준은 보안 수준의 선호가 아니라 '교체 작업을 계속할 것인가'라는 운영 질문입니다.

역할로 바꾸는 순서는 네 단계입니다

전환은 한 번에 하지 않습니다. 1단계로 현재 어느 서버가 어떤 열쇠를 쓰는지 목록을 만듭니다. 2단계로 각 열쇠가 실제로 호출하는 작업을 확인해 필요한 권한만 담은 역할을 만듭니다. 3단계로 서버에 역할을 붙이고, 열쇠는 아직 지우지 않은 상태로 동작을 확인합니다. 대개 라이브러리가 역할을 먼저 찾고 없으면 파일을 보기 때문에, 역할이 제대로 붙으면 코드 변경 없이 전환됩니다. 4단계로 열쇠를 비활성화하고 일정 기간 뒤 삭제합니다. 비활성화와 삭제를 나누는 이유는 문제가 생겼을 때 되돌릴 시간을 두기 위해서입니다.

교체 작업을 금액으로 환산합니다

학습용 가정으로 계산합니다. 가정값은 장기 열쇠가 심긴 서버가 20대이고, 열쇠 하나를 교체하고 확인하는 데 15분이 든다고 두겠습니다. 한 번의 교체 작업은 20 곱하기 15분으로 300분이고, 내부 시간 비용을 시간당 30,000원으로 가정하면 150,000원입니다. 분기마다 교체하는 정책이면 연 4회이므로 600,000원입니다. 이것이 중간 계산값입니다. 역할 방식으로 옮기면 이 항목이 사라지므로 최종 절감액은 연 600,000원입니다. 전환 작업 자체는 한 번으로 끝나고, 그 비용은 목록 작성과 역할 생성 시간으로만 발생합니다.

역할을 쓸 수 없는 자리가 남습니다

결론을 뒤집는 조건이 있습니다. 첫째, 우리 환경 밖에서 도는 프로그램에는 역할을 붙일 수 없습니다. 개발자 노트북이나 외부 협력사 시스템이 그렇습니다. 이 경우에는 열쇠를 쓰되 유효 기간과 권한을 최소로 좁히고 사용 기록을 남깁니다. 둘째, 오래된 라이브러리는 역할 기반 자격 증명을 찾지 못할 수 있습니다. 이때는 라이브러리를 올리는 작업이 전환의 선행 조건이 됩니다. 셋째, 역할을 너무 넓게 만들면 열쇠보다 위험해집니다. 서버에 침입한 공격자가 그 역할의 모든 권한을 쓸 수 있기 때문입니다. 그래서 역할마다 권한 범위를 적어 둡니다.

서버 운영 실행 전 점검표

• 어느 서버가 어떤 열쇠를 쓰는지 목록을 만들었다
• 실제 호출 작업만 담은 역할을 만들었다
• 역할을 붙인 뒤 열쇠를 비활성화하고 기간을 두어 삭제했다
• 역할을 쓸 수 없는 자리를 따로 분류했다