결제 API 키 로테이션: 접근 권한 대장부터 검증까지

시크릿 로테이션을 마치고 운영 키를 모든 주요 서비스에서 성공적으로 교체했습니다. 그런데 일주일 뒤 대사 작업이 돌아가지 않습니다. 잊혀 있던 스크립트가 여전히 이전 비밀값을 쓰고 있었던 것입니다. 형식상 로테이션은 끝났지만 운영상으로는 끝나지 않았습니다. 결제 접근 권한 관리는 대부분의 시간 동안 조용히 있는 사용처까지 포함한 사용처 대장에서 시작됩니다.

비밀값 없이 접근 권한 지도를 만들라

키마다 소유자, 환경, PG사 계정, 용도, 허용된 작업, 사용처 목록, 폐기 절차를 기록하십시오. 대장에는 보안 저장소로 가는 링크를 두되 키 값 자체는 넣지 않습니다. 주간 데이터 추출, 예비 핸들러, 고객 지원용 수동 유틸리티처럼 드물게 실행되는 작업은 따로 표시하십시오. 일반적인 애플리케이션 업데이트 때 잊기 쉬운 것이 바로 이런 작업입니다.

Stripe는 제한된 API 키, 안전한 보관, 노출 시 즉각적인 로테이션을 권장합니다. 구체적인 권한 구성은 제품마다 다릅니다. 그러므로 먼저 PG사가 제공하는 기능을 확인한 뒤, 각 컴포넌트에 꼭 필요한 접근 권한만 부여하십시오. 세밀한 제한 기능이 없다면 서비스 분리, 호출 통제, 접근 가능한 인원 축소로 보완하되, 동등한 수준의 보호를 약속하지는 마십시오.

업무 단위로 접근 권한을 나눠라

내부 서비스가 세 개인 플랫폼을 생각해 봅시다. '수납' 서비스는 허용된 결제 거래를 생성합니다. '리포트' 서비스는 대사에 필요한 정보를 읽습니다. '환불' 서비스는 승인된 환불을 실행합니다. 제안하는 구조에서는 공용 키 하나로 설정하는 편이 편하다는 이유만으로 리포트 프로세스가 돈을 보낼 권한을 갖지 않습니다. 환불 서비스는 자체 접근 권한과 별도의 작업 이력을 갖습니다.

웹훅 서명 검증에는 이를 위해 마련된 메커니즘을 사용합니다. 핸들러가 추가로 최신 상태를 조회해야 한다면 필요한 읽기 권한을 부여하십시오. 알림 서명용 비밀값과 API 호출용 서버 키를 '결제 비밀번호'라는 하나의 개념으로 뭉뚱그리지 마십시오. 둘은 용도도, 교체 절차도 다를 수 있습니다.

테스트 환경과 운영 환경도 설정과 접근 권한이 달라야 합니다. 테스트 보고서에는 내부 규정상 허용된다면 비밀값이나 설정의 버전 식별자를 적되, 비밀값 전체를 적지는 마십시오. 운영자는 키 값을 열어 보지 않고도 자신이 어떤 환경을 다루는지 알 수 있어야 합니다.

저장소에서 애플리케이션까지의 경로를 보호하라

비밀값 저장소는 접근 통제와 애플리케이션으로의 값 전달을 관리하는 서비스입니다. 하지만 저장소가 있다고 해서 누가 비밀값을 읽을 수 있는지에 대한 답이 나오지는 않습니다. AWS 인프라의 경우 IAM 문서는 최소 권한과 워크로드용 임시 자격 증명을 권장합니다. 이는 AWS 접근에 관한 내용이며, 그런 역할 자체가 외부 PG사의 키를 대체하지는 않습니다.

애플리케이션이 어디서 값을 받는지, 어떤 프로세스가 그 값을 읽을 수 있는지, 오류가 났을 때 값이 어디로 흘러갈 수 있는지 확인하십시오. 안전한 점검을 위해 실제 비밀값 대신 인위적인 마커를 사용하고, 테스트 로그, 빌드 보고서, 진단 페이지를 거치는 그 경로를 추적하십시오. 이런 테스트가 모든 유출이 없음을 증명하지는 못하지만, 원치 않는 구체적인 사본을 찾아내는 데는 도움이 됩니다.

OWASP는 비밀값 사용 감사와 그 수명 주기를 설명합니다. 실무 대장에서는 어떤 서비스가 접근 권한을 받았는지, 버전이 언제 바뀌었는지, 누가 변경을 승인했는지 볼 수 있으면 유용합니다. 이를 위해 로그에 비밀값 자체를 남길 필요는 없습니다.

정기 교체를 검증 가능한 절차로 진행하라

1. 1.PG사의 규칙을 확인합니다. 여러 키를 동시에 활성화할 수 있는지, 어떤 권한을 옮겨야 하는지, 이전 키는 어떻게 폐기하는지.
2. 2.승인된 보안 프로세스로 새 키를 준비하고 저장소에 보관합니다.
3. 3.알려진 목록에 따라 사용처를 업데이트합니다. 두 키를 병행 사용할 수 있다면 제한된 전환 기간을 두고, 그렇지 않다면 적절한 전환 순서를 합의합니다.
4. 4.허용된 작업과 예상되는 차단을 모두 확인합니다. 읽기 요청 하나가 성공했다고 필요한 모든 기능이 동작한다는 증거가 되지는 않습니다.
5. 5.드물게 실행되는 작업까지 업데이트되었는지 확인한 뒤 이전 키를 폐기하고, 계속 사용되는 곳이 없는지 점검합니다.

가상의 예에서 애플리케이션은 교체 후 정상 동작하지만, 주간 대사 작업은 아직 이전 설정을 보관하고 있습니다. 사용처 대장이 있으면 다음 실행 전에 이를 발견할 수 있습니다. 며칠 뒤 우연히 오류가 나기를 기다리지 말고, 드물게 도는 프로세스를 미리 점검 범위에 넣으십시오.

키에 금지된 작업을 확인하라

리포트 조회가 성공했다는 것은 그 키가 리포트를 읽을 수 있다는 뜻일 뿐입니다. 환불 권한이 없다는 것을 확인해 주지는 않습니다. 권한 세트마다 적절한 안전한 환경에서 네거티브 테스트를 만드십시오. 역할 범위를 벗어난 작업은 거부되어야 합니다. 실제 돈이 오가는 임의의 거래로 제한을 시험하지 말고, 제공사가 마련한 방법과 승인된 테스트 시나리오를 사용하십시오.

키를 보유한 서비스에 대한 사람의 접근도 따로 살펴보십시오. 직원이 비밀값을 읽는 것은 금지되어 있어도, 애플리케이션이 비밀값을 쓰는 컨테이너에서 임의 명령을 실행하는 것은 허용되어 있을 수 있습니다. 그렇다면 저장소에서의 조회 금지는 실제 접근 범위를 설명하지 못합니다. 권한 지도는 보기 좋은 vault 사용자 목록만이 아니라 실행 경로 전체와 관리자 권한까지 반영해야 합니다.

실제 비밀값 없이 하는 리허설

'진단 아카이브에서 키가 발견됨'이라는 상황으로 도상 훈련을 해 보십시오. 누가 접근 권한을 폐기할 수 있는가, 누가 예비 접근 수단을 갖고 있는가, 어떤 작업이 멈추는가, 사용 흔적은 어디서 찾는가? 장애가 나기 전에 답을 준비해 두십시오. 제품팀은 새 키가 아직 배포되지 않았을 때 서비스가 어떻게 안전하게 동작할지 따로 정합니다. 남의 계정이나 테스트용 정보로 몰래 넘어가는 것보다 이해할 수 있는 일시 중지가 낫습니다.

교체 후에는 인증 오류만이 아니라 기대한 작업이 사라지지 않았는지도 지켜보십시오. 야간 리포트는 메인 애플리케이션에서 아무 경보도 울리지 않은 채 그냥 생성되지 않을 수 있습니다. 로테이션 완료를 드물게 도는 작업까지 포함해 검증된 사용처 목록과 연결하십시오. 이런 기록은 '비밀값 갱신 완료'라는 체크 표시보다 유용합니다. 비즈니스 관점의 결과를 설명하기 때문입니다.

유출이 발생하면 우선순위가 바뀐다

노출이 의심되면 장애 대응 절차에 따라 움직이십시오. 영향받은 접근 권한을 신속히 폐기하거나 교체하고, 사용 내역을 평가하고, 필요한 증거를 안전한 방식으로 보존합니다. 빠른 복구를 위해 노출된 키로 되돌아가지 마십시오. 파일의 최신 버전에서 해당 줄을 지운다고 이미 만들어진 사본이 사라지지 않으며, 폐기를 대신하지도 않습니다.

잘 관리되는 연동은 네 가지 질문에 답할 수 있습니다. 누가 키를 쓰는가, 키에 무엇이 허용되는가, 어떻게 교체하는가, 이전 접근 권한이 더 이상 유효하지 않다는 것을 어떻게 확인하는가. 서비스 하나부터 시작해 이 사슬을 검증된 결과까지 완성하십시오.