프로젝트를 받아 보니 설정 파일에 DB 비밀번호가 있었다.
$db['default']['password'] = '...';
저장소에 그대로 들어 있었다.
Table of contents
Open Table of contents
문제 — 세 가지가 걸렸다
처음엔 뭐가 문제인지 잘 몰랐다. 우리끼리 보는 저장소인데 싶었다. 생각해 보니 세 가지가 있었다.
첫째는 이력에 남는다는 것이다. 한 번 올리면 지워도 이력에 남고 나중에 과거 시점을 받으면 나온다.
둘째는 사람이 늘면 퍼진다는 것이다. 저장소에 접근할 수 있는 사람이 늘면 비밀번호도 같이 늘어난다. 값을 바꾸지 않는 한 계속 유효하다.
셋째는 환경이 다르다는 것이다. 개발 서버는 개발 DB 를 보고 운영 서버는 운영 DB 를 봐야 하는데 파일이 하나니 매번 고쳐야 했다.
셋째가 바로 걸렸다. 개발용으로 고친 것을 올릴 뻔한 일이 있었는데 올렸으면 운영 설정이 개발 것으로 덮인다.
설정을 빼고 예시만 남겼다
설정 파일을 저장소에서 빼고 예시만 올렸다.
저장소: 설정 예시 파일
서버: 실제 설정 파일
// config.example.php
$db['default']['password'] = 'CHANGE_ME';
새로 받은 사람은 cp config.example.php config.php 로 복사해서 자기 값을 넣는다.
예시 파일에 부수 효과가 있었다. 무엇을 설정해야 하는지가 목록이 된다. 없으면 무엇을 넣어야 하는지 물어봐야 하는데 예시가 있으면 항목이 보인다.
svn propset svn:ignore 로 무시 목록에도 넣었다. 그런데 이 속성은 이미 올라간 파일을 빼 주지 않는다. 매뉴얼도 무시 패턴이 버전 관리에 넣는 그 한 번에만 적용되고 일단 관리 대상이 되면 더는 적용되지 않는다고 적어 뒀다.
그래서 svn rm --keep-local 로 저장소에서만 지우고 작업 사본에는 남겼다. 이 순서를 모르면 svn:ignore 를 걸어 둔 채로 계속 커밋된다.
이력에는 그대로 남아 있었다
파일을 지워도 지난 이력에는 값이 그대로 남아 있었다. svn cat -r 리비전 한 줄이면 그 시점 내용이 그대로 나온다.
지우는 것으로는 이미 퍼진 값을 무효로 만들 수 없었다. 파일만 지우면 이력에 옛 비밀번호가 남고 그것이 아직 유효하다.
그래서 비밀번호 자체를 바꿨다. 계정 비밀번호를 새로 발급하고 옛 것은 DROP USER 로 없앴다. 노출된 것은 바꾸는 것이 유일한 해결이고 저장소에서 지우는 것과 값을 무효로 만드는 것은 다른 조치였다.
계정과 권한과 경유
바꾸면서 서버마다 다르게 했다. 같은 비밀번호를 쓰면 하나가 새면 전부가 새고 다르게 하면 하나만 샌다.
다르게 하니 기억할 것이 늘었다. 적어 둬야 하는데 적어 두면 그것도 새어 나갈 수 있다는 문제가 남았다.
DB 계정도 사람마다 나눴다. 공용 계정이면 누가 무엇을 했는지 모르는데 개인 계정이면 로그에 남는다.
권한도 나눠서 대부분은 조회만 주고 변경은 필요한 사람만 줬다. 이게 보안만이 아니었는데 조회 권한만 있으면 실수로 지울 수 없다. 전체 권한이면 잘못 실행했을 때 지워진다.
운영 DB 는 아무나 못 붙게 하고 거치는 곳을 하나 뒀다. 그러니 누가 언제 붙었는지 로그가 한 곳에 모였다.
대신 한 단계를 더 거쳐야 해서 불편해졌다. 그래도 두기로 했는데 문제가 생겼을 때 기록이 있는 쪽이 필요하다고 봤기 때문이다.
정리
- 비밀번호가 저장소에 있으면 이력에 남고 접근자가 늘수록 퍼진다
- 환경마다 값이 다른데 파일이 하나면 매번 고치게 된다
- 설정을 빼고 예시만 올린다. 예시가 필요 항목 목록이 된다
svn:ignore는 이미 관리 중인 파일에는 적용되지 않는다svn rm --keep-local로 저장소에서만 지운다svn cat -r로 옛 리비전의 값이 그대로 나온다- 지우는 것과 무효로 만드는 것은 다른 조치다. 비밀번호 자체를 바꾼다
- 서버마다 다르게 하면 안전한데 관리할 것이 는다
- 계정을 나누면 누가 무엇을 했는지 남는다
- 권한을 줄이면 실수도 막힌다
- 거쳐 가는 곳을 두면 불편한데 기록이 한 곳에 모인다