공유 DB 계정 212개를 지우고, 권한 요청은 40분 안에 끝납니다

과제: 누가 들어왔는지 설명하기 어려운 구조

가온페이의 데이터베이스는 서비스가 커지는 동안 팀별 공유 계정으로 운영돼 왔습니다. 결제, 정산, 고객지원 조직이 각자 계정을 만들어 쓰다 보니 한 계정을 여러 사람이 함께 쓰는 일이 흔했고, 퇴사자나 부서 이동자의 접근을 제때 막았는지 확인하려면 인사 기록과 계정 목록을 일일이 대조해야 했습니다.

전자금융 관련 점검을 앞두고 보안팀이 가장 부담스러워한 질문은 단순했습니다. 특정 날짜에 특정 테이블을 조회한 사람이 누구였는가. 공유 계정 구조에서는 이 질문에 정확히 답할 수 없었습니다.

접근 방식: 계정이 아니라 요청으로

가온페이는 빗장 액세스를 도입하면서 먼저 공유 계정을 없애는 일부터 시작했습니다. 개발자와 운영자는 사내 SSO로 빗장에 로그인하고, 필요한 데이터베이스와 조회 범위, 사용 기간을 적어 권한을 요청합니다. 요청은 팀장과 보안 담당자로 이어지는 결재선을 따라 메신저로 전달되고, 승인되면 그 범위 안에서만 접속이 열립니다.

도입 첫 달에는 기존 계정을 바로 막지 않고 두 방식을 함께 운영했습니다. 빗장의 정책 시뮬레이션으로 지난 한 달 동안의 실제 접속 기록을 새 정책에 대입해 보고, 업무가 막히는 경우를 미리 찾아 규칙을 다듬었습니다. 그 뒤 팀 단위로 공유 계정을 순서대로 비활성화했습니다.

정산 데이터에는 보는 사람마다 다른 화면을

두 번째 과제는 정산 데이터였습니다. 고객지원팀은 결제 내역을 확인해야 하지만 카드번호나 계좌번호 전체를 볼 필요는 없습니다. 빗장 데이터 가드로 정산 관련 테이블을 스캔해 민감 컬럼을 분류하고, 역할별 마스킹 규칙을 연결했습니다. 같은 쿼리를 실행해도 고객지원팀에는 뒷자리만, 정산팀에는 전체 값이 보입니다. 원본 데이터는 그대로이기 때문에 애플리케이션을 고칠 필요가 없었습니다.

결과: 감사는 보고서를 고르는 일로

공유 계정 212개가 정리되면서 모든 접속은 사람과 요청 사유에 연결됐습니다. 권한 요청부터 실제 접속까지 걸리는 시간은 평균 40분 안쪽으로 줄었고, 대부분은 메신저 승인 한 번으로 끝납니다. 감사 기간이 되면 보안팀은 대상 시스템과 기간을 골라 보고서를 내려받고, 보고서에 붙은 검증값으로 원본 기록과의 일치 여부를 함께 제출합니다.

가온페이는 다음 단계로 사내에서 늘고 있는 AI 도구 사용을 같은 원칙 아래에 두는 방안을 검토하고 있습니다.