스프링 설정 파일과 보안

1. 설정 파일을 어떻게 관리할 것인가?

23년 10월 24일에(3주 전에) 간단하게 CI/CD 세팅을 완료하고 깊은 고민에 빠졌다. 데이터베이스 접속 정보가 포함된 설정 파일은 어떻게 관리하지?

첫 번째 방법: 프로젝트에 포함

첫 번째 방법은 설정 파일을 프로젝트에 포함해서 관리하는 것이다. 이 방법은 편리하게 설정 파일을 관리할 수 있다는 장점이 있지만, 공개 저장소의 경우 민감 정보가 그대로 노출되어 심각한 보안 위협을 일으킬 수 있다.

두 번째 방법: 암호화

두 번째 방법은 jasypt 등의 라이브러리를 사용해 민감 정보를 암호화해서 관리하는 것이다. 암호화된 리소스는 기존 리소스에 비해 비교적 안전하다는 장점이 있다. 그러나 단방향 암호화가 아닌 양방향 암호화이므로(DB 접속 정보는 필요에 따라 복호화해서 사용) 여전히 접속 정보가 노출될 가능성이 있다.

세 번재 방법: GitHub Secrets

세 번째 방법은 GitHub 저장소의 Secrets로 접속 정보를 관리하는 것이다. 각각의 깃헙 저장소는 민감 정보를 저장하기 위한 Secrets를 제공한다. Secrets는 한 번 생성하면 편집 시 기존 값을 확인할 수 없기 때문에 비교적 안전하게 관리할 수 있다. 다만 스프링 설정 파일 생성 및 빌드를 workflow 안에 추가하면 민감 정보가 GitHub Actions에 노출될 수 있으므로 주의가 필요하다. 자바의 실행 파일인 jar는 쉽게 압축 해제가 가능하기 때문이다.

네 번째 방법: 따로 관리

네 번째 방법은 실제 접속 정보와 설정 파일을 분리해서 관리하는 것이다. 프로덕션 서버가 해킹당하지 않는 이상 프로젝트 형상 관리 단계에서는 실제 데이터베이스 접근 방법을 알 수 없어 위의 세 방법보다 안전하다는 장점이 있다. 단점은 서버가 여러 개인 경우 각 서버의 접속 정보를 관리하기가 번거롭다. 또한 협업을 할 때 설정 파일을 따로 공유해야 한다.

2. 결론

나는 관리가 필요하지만, 보안적인 측면에서 가장 안전한 네 번째 방법을 선택했다. 어떤 보안적 절차가 추가된다고 해도 공개 저장소에 설정 파일을 노출시키고 싶지 않았다. 또한 설정 파일은 형상 관리를 통해 추척 할만큼 변경 사항이 많지 않았다. 만일 추후에 설정 파일이 자주 변경된다면 변경할 예정이다.

설정 파일의 위치

실제 접속 정보가 포함된 설정 파일은 'java -jar' 명령어가 실행되는 폴더에 위치해야 한다. 현재 프로젝트를 실행 시킬 서버 구조가 아래와 같다고 하자. . └── home ├── ubuntu ├── project_name │ └── application.properties <- A └── application.properties <- B 만일 project_name 폴더에서 실행한다면 application.properties는 A처럼 프로젝트 폴더에 위치해야 한다. 반면에 ubuntu 폴더에서 실행한다면 application.properties는 B처럼 ubuntu 폴더에 위치해야 한다.