본문으로 건너뛰기
NEW · Blast Radius: 유출된 API 키 대응 플레이북 (AWS·GCP·Azure)
문서 목차

모범 사례

담당자와 권한 운영

담당자 인계와 조직 역할을 함께 점검해 책임이 비는 시크릿을 줄입니다.

왜 담당자와 권한을 함께 보나

키를 만든 사람과 지금 서비스를 운영하는 사람은 다를 수 있습니다. 담당자를 지정하면 누가 조치를 이어갈지 분명해집니다. 조직 역할은 그 사람이 수행할 수 있는 작업을 정합니다. 퇴사 계정을 정리했다고 그 계정이 쓰던 키까지 폐기되는 것은 아닙니다.

권장 운영 방식

새 시크릿을 검토할 때 서비스와 사용 환경을 아는 사람을 담당자로 정합니다. 코드 작성자 정보를 바탕으로 현재 담당자를 찾습니다. 작성자가 지금도 서비스를 책임진다고 단정하지 않습니다. 담당자가 바뀌면 남은 조치와 서비스 사용처도 함께 인계합니다.

역할 권장 책임
소유자 조직 소유권과 소유자 전용 설정을 책임집니다. 부재나 퇴사 전에 소유권 인계 대상을 정합니다.
관리자 연동·알림·멤버 구성을 관리할 사람에게 부여합니다. 일상적인 시크릿 처리만 맡는 사람에게 관리자 역할을 부여하지 않습니다.
멤버 일상적인 시크릿 검토와 조치를 맡는 사람에게 우선 부여합니다. 개별 시크릿을 수정할 수 있는지는 담당 관계와 공유 정책도 함께 확인합니다.

설정 › 멤버·팀에서 멤버 역할을 확인합니다. 역할별 허용 작업은 역할과 권한을 기준으로 판단합니다. 메뉴가 보인다는 이유만으로 다른 사람의 시크릿까지 수정할 수 있다고 가정하지 않습니다.

퇴사나 팀 이동 때에는 소유자에서 소유자 미지정과 비활성 소유자 키를 확인합니다. 새 담당자를 정합니다. 이전 담당자가 알던 키를 교체하거나 폐기해야 하는지 검토합니다. 팀 접근 범위도 확인한 뒤 계정 정리를 마칩니다.

흔한 실수

권한 부족을 해결하려고 모두를 관리자로 올리면 연동과 멤버 설정까지 바꿀 수 있는 사람이 늘어납니다. 먼저 필요한 작업과 그 시크릿의 담당 관계를 확인합니다. 디렉터리 동기화로 계정이 비활성화되어도 키의 유효 상태와 실제 서비스 사용은 별도로 확인해야 합니다.

점검표

  • 각 서비스의 현재 담당자가 정해져 있는가.
  • 관리 역할이 필요한 사람에게만 부여되어 있는가.
  • 미지정·비활성 소유자 항목을 검토했는가.
  • 인계받은 사람이 사용처와 남은 조치를 알고 있는가.
  • 조직 소유자 부재 시 인계 절차가 정해져 있는가.