신뢰 vs 권한 — 작은 팀의 보안 모델
세 명짜리 팀에서 "모두를 믿으니 모두에게 권한을"이 얼마나 위험한지, 그리고 신뢰와 권한 분리가 왜 모순이 아닌지를 정리한다.
작은 팀에서 권한을 세밀하게 나누는 건 관료주의처럼 느껴진다. “우린 서로 다 믿는데 왜 DB에 readonly 계정을 써야 해?” 이 질문은 당연하다. 그런데 신뢰와 권한 분리는 서로 다른 문제를 다룬다.
신뢰는 의도에 관한 것이고, 권한은 실수에 관한 것이다
팀원을 믿는다는 말은 “그 사람이 나쁜 짓을 하지 않을 것”을 의미한다. 권한을 최소화한다는 말은 “실수가 일어났을 때 영향 범위를 줄인다”는 의미다. 두 가지는 전제가 다르다.
조회 쿼리를 실행할 때 프로덕션 DB에 write 권한이 있는 계정을 쓰면, 실수로 UPDATE 문에 WHERE 절이 빠져도 바로 반영된다. readonly 계정을 쓰면 같은 실수가 에러로 끝난다. 악의 없는 실수가 서비스 장애가 되는 것을 막는 구조다.
우리가 실제로 운영하는 방식
환경을 분리한다. 로컬, 스테이징, 프로덕션은 접속 정보가 다르다. 로컬에서 테스트하다가 프로덕션 데이터를 건드리는 일이 구조적으로 불가능하게 한다.
작업별 계정을 쓴다. 애플리케이션 런타임 계정, 마이그레이션 계정, 읽기 전용 분석 계정을 분리한다. 런타임 계정에는 DDL 권한을 주지 않는다.
비밀 값은 코드에 쓰지 않는다. 환경 변수나 시크릿 매니저를 통해 런타임에 주입한다. .env 파일이 저장소에 들어가는 것을 막기 위해 .gitignore 외에도 pre-commit 훅으로 이중 확인한다.
화면에 민감 정보를 노출하지 않는다. 채팅, 화면 공유, 스크린샷에 자격증명이 찍히는 상황을 줄이는 게 목적이다. 발생했을 때의 처리 절차는 별도로 정해두었다.
팀 규모가 작을수록 이게 더 중요한 이유
큰 조직에는 누군가가 실수를 발견하고 막는 레이어가 여럿 있다. 세 명짜리 팀에는 그 레이어가 없다. 사람을 믿지 않아서가 아니라, 실수를 감지하고 막아줄 구조 자체가 부재하기 때문에 시스템이 더 단단해야 한다.
— by slecs