7-8년 전 쯤인가... configuration server를 개발한 적이 있다.


DB 아이디와 패스워드를 암호화하여 소스 리파지토리 서버, 노트북, 물리 장비가 해킹되더라도 아이디/패스워드가 노출되지 않도록.. configuration server를 개발했다.


빌드 툴, 빌드/배포 서버에서 ant/maven 플러그인으로 configuration server에 접속해 암호화된 정보를 읽도록 하고 파일을 교체하도록 했다.  또한 개인정보보호법에 따라 3개월마다 무조건 DBA가 id와 패스워드를 변경하게 하고 DBA가 책임을 지도록 했다.





요즘은 어떨까?



https://12factor.net/ko/config 도 이런 문맥에서 얘기하고 있다. 


애플리케이션의 설정 배포 (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다.

  • 데이터베이스, memcached 등 백엔드 서비스들의 리소스 핸들
  • Amazon S3 이나 트위터 등의 외부 서비스 인증 정보
  • 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값

애플리케이션은 종종 설정을 상수로 코드에 저장합니다. 이것은 Twelve-Factor를 위반하며, Twelve-Factor는 설정을 코드에서 엄격하게 분리하는 것을 요구합니다. 설정은 배치마다 크게 다르지만, 코드는 그렇지 않습니다.

애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 테스트는 어떠한 인증정보도 유출시키지 않고 코드베이스가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.


ansible(https://docs.ansible.com/ansible/2.4/vault.html)의 경우는 암호 파일을 두어 배포를 가능하게 해두었다. 

Posted by 김용환 '김용환'