[DevOps] 서버용 패스워드는 어떻게 관리해야 하는가

알약이나 알집 시리즈를 사용해 본 사람이라면, 알패스(ALPass)에 대해 한번 쯤 들어본 적이 있을 것이다. 알패스는 모든 웹사이트의 패스워드를 저장하고, 웹사이트 접속시 자동으로 패스워드 입력을 대행해주는 소프트웨어이다. 최근에는 라스트패스 또는 크롬 패스워드 같은 플러그인도 많이 사용된다.

개인의 패스워드 관리를 대행하는 알패스

이 소프트웨어의 목적은 수많은 패스워드를 직접 관리하는 데에서 오는 부담을 피하고, 민감한 정보의 관리를 전문 툴에 위임하는 데 있다. 이를 엔터프라이즈 영역으로 확장하면 오늘 언급할 시크릿 관리 툴로 이어진다. 볼트 서버나 AWS의 시크릿 매니저, 타이코틱의 시크릿 서버 등이 대표적인 소프트웨어로, 이들은 결국 ‘엔터프라이즈 환경에서 패스워드를 어떻게 관리해야 안전한가’ 하는 물음에 대한 답이라고 할 수 있다.

왜 서버용 패스워드를 관리해야 하는가

온라인 서비스를 운영하기 위해 필요한 비밀 정보는 많다. 애플리케이션에서 사용해야 하는 것들 중에서 외부로 노출되면 안되는 계정과 패스워드, 엑세스 토큰, API 인증 키 같은 것들 말이다. 특히 서드 파티 솔루션을 연동하는 경우 관리해야 할 패스워드는 굉장히 많아지는데, MySQL 같은 RDB 서버를 이용하려면 DB 접속용 패스워드를 관리해야 하고, 특정 부분에 NoSQL이나 TSDB를 덧붙인다면 이를 위한 패스워드도 관리 대상이다. 성능 개선을 위해 레디스를 연동하면 레디스 패스워드도 관리해야 하고, MQ를 이용할 경우에도 접속용 패스워드를 관리해야 한다.

이 뿐만이 아니다. CI를 구축하려면 젠킨스 등 빌드 서버가 소스 컨트롤 시스템(ex. 깃허브)에서 소스 코드를 내려받을 수 있도록 인증키를 관리해야 하고, 도커라이징된 컨테이너 이미지를 AWS ECR같은 레포지토리에 푸시하기 위한 인증키도 필요하다. SSH 연동을 하려면 SSH 비밀키도 관리해야 한다.

결론적으로, 하나의 서비스를 구축하기 위해 관리해야 하는 민감한 데이터는 상당히 많다.

문제는 이런 데이터를 어떻게 관리해야 하는가에 있다. 비밀번호를 조심해서 관리해야 한다는 것을 모르는 사람은 없지만, ‘그렇다면 어떻게 관리해야 안전한 것인가’에 대해 명확한 답을 내릴 수 있는 전문가는 많지 않다.

우리 주변에서 가장 쉽게 찾아볼 수 있는 대응책 중 하나는 잘 관리할 것이라는 근거없는 믿음으로 개발자 PC에서 개별로 관리하는 것이다. 그그나마 조금 나은 경우에는 AWS나 GCP 같은 클라우드용 접속 정보를 구글 스프레드 시트나 엑셀에 비밀번호를 걸어 관리하기는 한다.

이런 식의 관리 체제 하에서 개발자는 패스워드를 서버 설정 파일 내에 때려 넣고 서버를 패치한다. XML, Properties 등의 설정 파일을 HTTP 프로토콜을 통해 직접 접근할 수 없는 영역(예를 들면 /WEB-INF/와 같은)에 저장해 두고 소스 코드가 읽어서 사용하도록 하는 방식 말이다. 개발 환경, 테스트 환경, 서비스 환경 별로 설정 파일을 나누어 놓으면 골치아플 일도 없고, 꽤나 편리하다.

결론부터 말하자면, 이는 절대 지양해야 할 방식이다. 개발자 중 누군가 실수로 소스 컨트롤 시스템에 패스워드를 올릴 수도 있고, 악성 이메일을 통해 감염된 개발자의 PC를 통해 패스워드가 유출될 위험성도 존재한다. 패스워드를 바꿀 때마다 서버를 패치해야 하는 번거로움 탓에 1년 이상 기존 패스워드를 그대로 유지하는 경우도 있다. 심지어 패스워드를 공유했던 누군가 퇴사하는 경우에도 말이다.

Q) 그럼 어떻게 해야 하는 건가요?

완벽한 방법은 없겠지만, 권장할 만한 최선의 방법은 있다. 바로 시크릿 관리용 툴을 사용하는 것이다. 툴(Tools)라고는 하지만 실제로는 서버다. 민감한 정보를 안전하게 관리해주는 전용 서버를 두고, 패스워드나 인증 키처럼 중요한 값은 모두 이 서버를 통해 관리하는 것이다.

시크릿 관리 툴을 도입했을 때 얻을 수 있는 이점

시크릿 관리 툴을 도입했을 때의 이점에 대해 알고 싶다면, 이를 도입하지 않은 상태를 연상해보면 된다. 신규 개발자가 입사했다고 가정하자. 아래와 같은 대화를 떠올리기는 그리 어렵지 않다.

"플랫폼 DB 접속 패스워드 어디에 있어요?"

"설정 파일 보시면 되요"

"아 여기에 있군요. OK"

시간이 흘러 기존 개발자가 퇴사하는 상황이 되었다. 퇴사자는 DB 접속 패스워드를 알고 있으므로, 안전을 고려한다면 패스워드를 변경해야 한다. 회사 내 시스템 보안팀이 있다면 다음과 같은 대화가 오고 갈 것이다.

"ㅇㅇㅇ님이 퇴사하셔서, DB 패스워드랑 클라우드 엑세스 키 모두 변경해야 합니다. 오늘 퇴사하니 패스워드 로테이션 해주세요"

"중요한 이벤트 진행 중이라서 서비스 중단하기가 곤란한데요"

"그래도 오늘 새벽에 서비스 점검 공지 걸고 패치해주세요. 퇴사자 발생시 패스워드를 변경하는 것이 원칙입니다"

회사가 커져서 개발자가 100명쯤 된다고 가정하자. 한 달에 두 명씩 퇴사한다면 우리의 서버 팀은 한달에 두번씩 설정 파일을 변경해 가며 새로 패치해야 한다. 그것도 퇴사 날짜에 맞춰서. 끔찍한 일이다.

시크릿 관리 툴은 이런 상황을 손쉽게 해결해준다. 모든 패스워드는 시크릿 관리 툴을 통해 관리하며, 개발자는 단지 시크릿 관리 툴에 접근할 권한만 가진다. 애플리케이션이나 시스템이 알아야 할 패스워드는 시크릿 관리 툴이 개발자를 대신하여 DB 서버에서 발급받은 후 전달할 수 있으므로, 시스템만 잘 연동해 두면 굳이 접속용 패스워드를 개발자가 알 필요가 없는 것이다. (물론 알려고 마음먹으면 알 수는 있겠지만 로테이션이 쉽기 때문에 크게 의미는 없다) 기존 개발자가 퇴사할 경우에도 보안팀은 시크릿 관리 툴에서 기존 개발자에 부여된 권한만 삭제하면 된다.

대부분의 시크릿 관리 툴은 다음과 같은 기능을 지원한다.

  1. 보안 저장소 설정 - 민감한 정보를 안전하게 저장하기 위해 암호화된 중앙 집중식 저장소를 사용한다.
  2. 권한 검색 - 서비스나 소프트웨어에 사용되는 관리자 권한과 루트 권한을 식별하여 엑세스를 제한할 수 있다.
  3. 엑세스 위임 - 필요에 따라 패스워드를 생성할 수 있는 엑세스 권한을 위임받고, 계정과 패스워드 등을 대신 관리한다.
  4. 세션 관리 - 정보를 요청하고 관리하는 세션을 만들고, 모니터링하고 기록한다. 이후 해당 데이터는 보안 감사시 활용된다.
  5. 동적 API 제공 - 사용자 및 애플리케이션이 시크릿 관리 툴의 API를 호출하여 동적으로 시크릿 데이터를 로딩할 수 있다.

시크릿 관리 툴이 하는 역할은 명확하다. 암호화된 물리 스토리지 계층에 패스워드를 저장하고, 이를 안전하게 서버까지 전달한다. 동적으로 시크릿 정보를 발급받아 전달하기 때문에, 발급된 시크릿이 파기되더라도 새로 발급받아 제공하면 그 뿐이다. 시스템이 연동된 후에는 개발자가 애플리케이션의 설정 파일에 패스워드를 직접 설정할 필요가 없어진다. 덕분에 운영 환경에서 시크릿 데이터에 대한 개발자의 개입을 최소화할 수 있으며, 이를 통해 안전한 엔터프라이즈 시크릿 관리 환경을 구성할 수 있다.

시크릿 관리 툴의 종류

대표적인 시크릿 관리 툴에는 다음과 같은 것들이 있다.

  • 하시코프 사의 볼트(Vault)
  • 타이코틱 사의 시크릿 서버(Secret Server)
  • 아마존 클라우드의 시크릿 매니저(AWS Secret Manager)
  • 도커 시크릿(Docker Secret)
  • 매니폴드의 토러스 CLI(Torus CLI)
  • 스퀘어의 Keywhiz

이들 중에서 많이 사용되는 것으로는 하시코프의 볼트와 타이코틱의 시크릿 서버, 그리고 AWS의 시크릿 매니저 정도를 꼽을 수 있다. 도커 시크릿은 컨테이너 기반 환경에서만 사용 가능하다는 제약이 있다.

1. 볼트(Vault)

vault-logo

볼트는 데브옵스 계의 명가인 하시코프(Hashcorp)에서 만든 시크릿 관리 전용 솔루션이다. API 키, 패스워드, 인증서 등 접근 제어가 필요한 모든 데이터에 적용할 수 있다. 서버 형태로 설치 후 사용 가능하며, 커맨드 라인 방식의 클라이언트를 지원한다.

시크릿 엔진(Secret Engine)이라고 불리는 다양한 컴포넌트를 사용하면 AWS, GCP, Azure 등의 클라우드와도 쉽게 연동할 수 있기 때문에, 클라우드 기반의 서비스를 구축하는 경우 테라폼(Terraform)과 함께 반드시 구축해야 할 운영 환경 중 하나로 꼽힌다. 여행 앱으로 유명한 트리바고(Trivago)에서 사용하고 있으며, 필자의 회사에서도 사용하고 있다.

오픈 소스로 제공되며, 다양한 설치 버전을 제공하고 있다. 맥 사용자의 경우 brew 같은 패키지 관리 소프트웨어를 통해 자신의 컴퓨터에 간단히 설치해 볼 수 있다는 장점이 있다.

2. 시크릿 서버(Secret Server)

secretserver-logo

시크릿 서버는 계정 정보 관리 솔루션 전문 기업인 타이코틱 사에서 제공하는 시크릿 관리 전용 솔루션이다. 볼트와 마찬가지로 서버 형태로 설치 후 사용 가능하지만, 클라우드 환경을 지원하기 때문에 SaaS 방식으로도 사용할 수 있다. 볼트와 함께 가장 많이 사용되고 있는 솔루션이기도 하다. 볼트와 비슷한 기능을 제공하지만 편의성이나 사용의 용이성 등에서 볼트보다는 조금 더 편리하다는 평가를 받고 있다. 특히 시크릿 서버는 웹 콘솔을 지원하므로, CLI 모드만 지원하는 볼트보다는 사용성 면에서 확실히 우위에 있다고 할 수 있다.

오픈 소스인 볼트와 달리 유료 라이선스로 운영된다.

3. 시크릿 매니저(Secret Manager)

secretmanager-logo

시크릿 매니저는 아마존 클라우드에서 제공하는 시크릿 관리 전용 솔루션이다. 사용량에 따라 과금되며, 클라우드 방식으로만 제공되므로 온프레미스 환경에서 직접 서버를 설치하는 것은 불가능하다.

AWS 서비스이니만큼 Amazon RDS, Redshift, DocumentDB 등 각종 AWS DB와 기본적으로 통합되어 있으며, Lambda 함수를 통해 OAuth 토큰이나 API 키 등을 읽어오도록 구성이 가능하다.

다음 포스팅에서는 이들 중에서 볼트 서버를 사용하는 요령에 대해 알아보도록 하겠다.