[Backend] application.properties, application.yml 보안 관리와 협업 효율성 높이기

해당 글은 피우다 프로젝트 공모전 DOSI:RAK 서비스를 만들면서 했던 내용이다

 

나는 여러가지 프로젝트를 하면서 의문이 들었던 문제점 이 있었다 

그건 바로! 

 

appcliation.properties 나 application.yml 파일에 있는 민감한 정보

즉, 데이터베이스 아이디, 비밀번호 등을 어떻게 할것인가? 이다

 

이 문제점은 당연하게 혼자 프로젝트하면 상관이 없다 하지만 github에 협업을 하고 포트폴리오나 그런 것 때문에 repository를 private이 아닌 public으로 수정함으로써 문제가 되는 부분이다 

 

작자는 My-books라는 프로젝트에서는

이런 민감한 정보들을 nhn cloud secure key manager를 통해 암호화 하여 처리 했지만 

nhn cloud 서비스가 아닌 걸로 사용했을때는 어떤 방식으로 할까? 라는 의문점을 가지고 시작한 모험? 이다 

---

문제 상황

 

지금 우리 backend repository는 private로 되어 있다 

이 프로젝트가 끝나고 우리는 문서화를 해야한다 하지만 이 repository가 private 다 보니 문서화를 하더라도 의미가 없어진다 

 

 

하지만!

application.properties 설정 파일이 노출이 되어 버린다.... 

 

왜? 이게 노출이 되면 안되냐라고 물어본다면 

이런식으로 민감한 정보들이 노출이 되어버린다

 

특히! 서버 아이디, 비밀번호가 노출이 되어버린다 

 

그럼 이런 설정 파일을 프로젝트에서 어떻게 할까?

-> .gitignore로 저런 파일들을 원격 저장소에 노출이 안되게 한다 

 

그럼! ci/cd 할때 오류가 나지 않나요?

-> 그래서 ci/cd할때는 서버에서 저 설정 파일을 만들어서 jar로 한다고 한다

 

저 내용들은 실질적으로 어디서 가지고 있다가 설정 파일을 만들어요? 

github에 secrets로 관리를 하여 

이렇게 ci/cd 할때 설정 파일을 서버단에서 만들어준다 

 

그럼 협업할때 저 파일 관리는 어떻게 해야하나요? 

-> 보통 하는 방식은 notion으로 설정파일을 관리를 해준다 

 

이런 방식으로 관리를 해준다 

 

 

하지만 나는 이런 방식으로 하면서 단점을 발견한다 

 

1. 설정 파일이 수정이 되면 secrets 에 저장 해 놓은 설정 파일을 또 수정을 해야한다 

2. ci/cd과정에서 설정 파일이 오류가 나면 왜 어떤 오류가 났는지 찾기가 쉽지 않았다

3. 그리고 notion과 secrets에 설정 해 놓은 설정 파일을 둘다 업데이트를 해야한다 

 

좀 번거로운 부분들이 많았다

 

그래서 좀 더 나은 방법이 없는지 찾아 보았다

 

찾은 방법

1. 설정 값들 암호화 하는 방식

2. 설정 파일을 private repository 로 관리를 하여 메인 repository에 sub module로 등록해서 사용하는 방법

 

위에 찾은 방법을 보면 

대부분의 사람들은 1번 방법을 많이 고민 했을 것이다 -> 작자도 그렇게 생각한다 (왜냐하면... 보안학과 다 보니 그렇다)

 

하지만 나는 2번의 방법을 채택했다 

 

---

서브모듈 방법을 채택한 이유

 

1. 보안성 강화

 

 서브모듈을 사용하면 설정 파일을 별도의 private repository로 관리할 수 있기 때문에, 메인 프로젝트의 public repository에 민감한 정보가 노출되지 않게 할 수 있다

또한, 서브모듈에 저장된 설정 파일을 암호화하여 관리할 수 있어 추가적인 보안 레벨을 더할 수 있습니다

 

즉, 서브모듈로 관리를 하여 노출되지 않게 하고 또 여기서 암호화 하여 보안을 더 강화할 수 있다는 이점을 생각했다

 

 

2. 중앙 집중식 관리

 

설정 파일을 별도의 repository로 관리하면, 프로젝트가 커지거나 팀원들이 많아질수록 설정 파일을 중앙에서 관리할 수 있다는 장점이 있다.

각 팀원들이 설정 파일을 수정할 때마다 이를 관리하는 것이 수월해지고, 각자의 환경에 맞게 쉽게 업데이트할 수 있다.

설정 파일을 수정할 때마다 서브모듈만 업데이트하면 되기 때문에, 다른 방법들에 비해 훨씬 효율적이고 체계적인 관리가 가능하다.

 

 

3. 협업 효율성 증대

 

서브모듈을 사용하면, 설정 파일을 공유해야 할 때마다 매번 Secrets나 Notion 같은 다른 방법으로 업데이트하는 번거로움이 사라진다.

모든 설정 파일은 서브모듈을 통해 중앙화되어 관리되므로, 팀원들은 서브모듈을 클론하거나 업데이트하는 것만으로 최신 설정 파일을 자동으로 받게 된다.

이렇게 하면 설정 파일에 대한 변경 사항을 더 쉽게 추적할 수 있고, 협업 시 발생할 수 있는 혼선도 줄일 수 있다.

 

 

4. CI/CD 과정에서 유연성 확보

 

CI/CD 파이프라인에서 설정 파일을 서버에서 생성하는 방식은 설정 파일의 변경이나 업데이트가 있을 때마다 CI/CD 파이프라인을 수정해야 하는 번거로움이 발생할 수 있다.

반면 서브모듈을 사용하면, 설정 파일을 서브모듈로 분리하고 이를 별도로 관리하므로 CI/CD 과정에서 해당 설정 파일을 쉽게 업데이트하거나 변경할 수 있다.

서버에서 설정 파일을 수동으로 생성하는 방식보다는 훨씬 효율적이고 유연하다.

 

 

5. 버전 관리 및 추적 용이

 

서브모듈은 Git을 사용하여 버전 관리가 가능하므로, 설정 파일의 변경 이력을 추적하는 데 매우 유용하다.

예를 들어, 특정 설정 파일이 변경되었을 때, Git의 커밋 기록을 통해 언제, 누가, 어떤 변경을 했는지 쉽게 확인할 수 있다.

이를 통해 설정 파일의 변경 내역을 정확하게 파악하고, 문제가 발생했을 때 빠르게 원인을 찾아낼 수 있다.

 

특히 나는 5번이 제일 중요하다고 생각한다

왜냐하면! 협업을 하면서 누군가가 실수를 하여 설정값을 누락했던가 등등의 문제점이 발생한다 

만약 그렇다고 하면 커밋 기록을 확인하여 누락된게 있는지 누가 왜 어떻게 변경했는지 쉽게 알아 볼수 있으니까이다 

 

---

설정 파일 Sub Module 방법

 

이제 설정 파일을 private repository로 따로 관리를 하여 sub module화를 하는 방법인데! 

여기서 중요한 점이 또 있다 

이미 전에 커밋된 기록들을 보면 설정 파일에 대한 커밋 기록들이 있다...

 

그럼 어떻게 해줘야 할까?

 

일단 .gitignore에 설정 파일을 등록해라 라는 말은 생략할거다 전에 이미 설정을 해뒀다고 가정을 하고 시작할거다

 

1. BFG Repo-Cleaner 설치

BFG Repo-Cleaner는 Git 저장소에서 불필요하거나 민감한 파일을 빠르고 쉽게 삭제할 수 있도록 돕는 도구이다 

이 도구를 일단 설치를 하자 

brew install bfg

 

2. application.properties, application.yml 파일 제거 

bfg 를 이용해서 Git 저장소에서 위의 설정 파일의 모든 기록을 제거한다 

bfg --delete-files application.properties
bfg --delete-files application.yml

 

3. 정리된 내용을 원격 에 push를 한다

git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

 

 

이렇게 하면 git history에는 해당 파일의 기록들이 완전히 사라지게 된다

오! 신기하다

 

이제 repository를 public으로 설정을 해도 문제가 없어진다

 

일단 config라는 private 한 repository를 만들고 해당 설정 파일을 만들어서 추가 했다 

 

이제 backend repository에 이 config repository를 서브모듈로 등록 할 것 이다

git submodule add https://github.com/DOSI-RAK/config.git

이런식으로 등록하면 

이런식으로 config 파일이 등록이 될거고 .gitmodules 파일과 파일 내용으로 path, url이 생성이 될것이다 

 

 

 

원격 저장소에서 보면 이런식으로 commit hash 와 함께 config가 private 으로 관리되고 있다는 것을 알 수 있다

 

 

이제 그럼 만약 config안에 설정 파일을 수정을 한다면 어떻게 해야할까?

 

config안에 설정파일이 원격에서 수정이되었다고 가정을 해서 해보자 

 

cd config 하여 config 파일 위치에서 

git pull --recurse-submodules https://github.com/DOSI-RAK/config.git

이렇게 원격에 있는 수정 사항을 가져오면 된다 이 부분이 조금 번거롭다 

왜냐하면 뒤에 url를 다 작성해야 하니까...

 

 

이제 여기서 또 한가지 의문점이 든다 

이렇게 해버리면 로컬에서 작업하면서 테스트 할때 어떻게 해야하나요? resources에 없잖아요... 

 

이 부분은 

processResources.dependsOn('copySecret')

tasks.register('copySecret', Copy) {
    from './config' // 서브 모듈 디렉토리 경로
    include "*.yml"  // 설정 파일 복사
    into 'src/main/resources'  // 붙여넣을 위치
}

 

build.gradle 파일에 이렇게 build시에 설정 파일을 만드는 코드를 작성해야한다 

 

이런식으로 build시에 만들어지거나 수정이 되어 진다 

 

그럼 ci/cd시에 서버에는 resources에 설정 파일 없어서 오류가 나지 않을까요?

-> 아니다 왜냐하면 위에 우리가 설정한 것 처럼 서버에서도 build시에 config에 있는 설정파일을 resources에 복사를 하여 쓰기 때문이다 

 

 

 

그럼 이제 잘 되는지 확인해보자 

 

하... 항상 한번에 성공하는게 없다

 

로그랑 오류를 보면 대충 설정파일이 없어서 오류가 난다는 것을 확인했다 

그래서 찾아 보았더니 submodule이라고 해도 다른 repository에 권한이 없으면 못가져온다는 것을 확인했고 

 

이걸위해서 token을 을 발급 받았다 

 

이런식으로 토큰을 생성 하면 된다 

 

해당 토큰을 repository Secrets에 넣는다

ci/cd 에서 token과 submodules true 설정 값을 입력하면 된다 

 

 

 

성공!

 

 

 

 

 

이렇게 서브모듈을 활용한 설정 파일 관리 방법을 통해 민감한 정보를 안전하게 처리하고, 협업 환경에서 발생할 수 있는 문제들을 효율적으로 해결할 수 있었다.

서브모듈을 사용함으로써 설정 파일의 보안성을 강화하고, 중앙 집중식 관리와 CI/CD 과정에서의 유연성을 확보할 수 있었다.

이 방법은 협업 환경에서의 번거로운 관리 작업을 줄이고, 설정 파일 변경 이력을 쉽게 추적할 수 있어 더욱 효과적인 관리가 가능하다는 장점이 있다.