Vault를 통한 시크릿 관리 완벽 가이드

Ansible Vault를 활용한 시크릿 관리의 모든 것을 다룹니다. 민감한 정보를 안전하게 암호화하고, CI/CD 파이프라인에서 효과적으로 활용하는 방법까지 실무 중심으로 설명합니다.

---

목차

1. Ansible_Vault_개념
2. 파일_암호화_및_복호화
3. 암호화된_변수_사용
4. Vault_비밀번호_관리
5. CICD에서_Vault_활용
6. Vault_보안_베스트_프랙티스

---

1. Ansible Vault 개념

김개발 씨는 새로운 프로젝트에 투입되어 설레는 마음으로 Git 저장소를 클론받았습니다. 그런데 코드를 살펴보다가 깜짝 놀랐습니다.

데이터베이스 비밀번호가 그대로 YAML 파일에 적혀 있었던 것입니다. "이러면 안 되는 거 아닌가요?"

Ansible Vault는 민감한 데이터를 암호화하여 안전하게 보관하는 Ansible의 내장 기능입니다. 마치 금고에 귀중품을 넣어두는 것처럼, 비밀번호나 API 키 같은 정보를 암호화된 형태로 저장합니다.

이를 통해 코드를 Git에 올려도 민감한 정보가 노출되지 않습니다.

다음 코드를 살펴봅시다.

# 암호화되지 않은 위험한 방식 (절대 하지 마세요!)
# vars/database.yml
db_password: "super_secret_123"
api_key: "sk-1234567890abcdef"

# Vault로 암호화한 안전한 방식
# 터미널에서 실행
ansible-vault create vars/secrets.yml

# 암호화된 파일의 내용 (읽을 수 없음)
$ANSIBLE_VAULT;1.1;AES256
36613439653136323863383266656137
31326234613465623165396265626533
65323366643561373833313932373834

김개발 씨는 입사 첫 주부터 큰 충격을 받았습니다. 회사의 레거시 코드를 보니 데이터베이스 비밀번호, AWS 액세스 키, API 토큰 같은 민감한 정보들이 버젓이 평문으로 저장되어 있었습니다.

심지어 이 파일들이 Git 히스토리에 고스란히 남아 있었습니다. 선배 개발자 박시니어 씨가 김개발 씨의 당황한 표정을 보고 다가왔습니다.

"걱정 마세요. 우리 팀도 최근에야 Ansible Vault를 도입했거든요.

이제 새 프로젝트부터는 모든 시크릿을 Vault로 관리하고 있어요." 그렇다면 Ansible Vault란 정확히 무엇일까요? 쉽게 비유하자면, Vault는 마치 집에 있는 금고와 같습니다.

현금이나 귀금속, 중요한 서류를 아무 데나 두면 도둑이 쉽게 가져갈 수 있습니다. 하지만 금고에 넣어두면 비밀번호를 아는 사람만 열 수 있습니다.

Ansible Vault도 마찬가지로, 민감한 정보를 AES256이라는 강력한 암호화 알고리즘으로 보호합니다. Vault가 없던 시절에는 어떤 일이 벌어졌을까요?

개발자들은 비밀번호를 환경 변수로 관리하거나, 별도의 설정 파일을 .gitignore에 추가하는 방식을 사용했습니다. 하지만 이 방법에는 치명적인 문제가 있었습니다.

새로운 팀원이 합류할 때마다 시크릿을 일일이 전달해야 했고, 서버를 새로 세팅할 때마다 수동으로 설정해야 했습니다. 더 큰 문제는 누군가 실수로 시크릿이 담긴 파일을 커밋하면, Git 히스토리에서 완전히 제거하는 것이 거의 불가능하다는 점이었습니다.

바로 이런 문제를 해결하기 위해 Ansible Vault가 등장했습니다. Vault를 사용하면 암호화된 파일을 Git에 안전하게 커밋할 수 있습니다.

파일 자체는 저장소에 있지만, Vault 비밀번호를 모르면 내용을 전혀 알 수 없습니다. 팀원들은 같은 Vault 비밀번호를 공유하여 필요할 때 복호화해서 사용합니다.

위의 코드를 살펴보면, 암호화되지 않은 파일에는 비밀번호가 그대로 노출되어 있습니다. 반면 Vault로 암호화한 파일은 $ANSIBLE_VAULT로 시작하는 의미 없는 문자열로 보입니다.

이 문자열은 AES256으로 암호화된 결과물입니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 결제 API 키, 배송 조회 API 키, 데이터베이스 접속 정보 등 수많은 시크릿이 필요합니다.

이 모든 정보를 Vault로 암호화하면, 코드 리뷰 때도 안심하고 PR을 올릴 수 있고, 새 팀원에게 저장소 접근 권한을 줄 때도 걱정이 없습니다. 하지만 주의할 점도 있습니다.

Vault 비밀번호 자체는 어딘가에 안전하게 보관해야 합니다. 이 비밀번호마저 Git에 커밋하면 아무 의미가 없습니다.

보통 1Password, LastPass 같은 비밀번호 관리자나, AWS Secrets Manager 같은 별도의 시크릿 관리 서비스를 함께 사용합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "그러면 지금부터 새로 만드는 설정 파일은 모두 Vault로 암호화하면 되겠네요!"

실전 팁

💡 - Vault 비밀번호는 최소 16자 이상, 특수문자를 포함하여 강력하게 설정하세요

• 암호화할 파일은 secrets.yml처럼 명확한 이름을 붙여 관리하면 실수를 줄일 수 있습니다

---

2. 파일 암호화 및 복호화

김개발 씨는 Vault의 개념을 이해했지만, 막상 실제로 파일을 암호화하려니 어디서부터 시작해야 할지 막막했습니다. "create, encrypt, decrypt...

명령어가 왜 이렇게 많은 거죠?" 박시니어 씨가 웃으며 대답했습니다. "각각 상황에 맞는 명령어가 있어요.

하나씩 알아볼까요?"

Ansible Vault는 상황에 맞는 다양한 명령어를 제공합니다. create는 처음부터 암호화된 파일을 만들고, encrypt는 기존 파일을 암호화하며, decrypt는 암호화된 파일을 평문으로 되돌립니다.

이 명령어들을 적절히 활용하면 시크릿 관리가 한결 수월해집니다.

다음 코드를 살펴봅시다.

# 새로운 암호화 파일 생성 (에디터가 열림)
ansible-vault create vars/secrets.yml

# 기존 평문 파일을 암호화
ansible-vault encrypt vars/database.yml

# 암호화된 파일을 평문으로 복호화
ansible-vault decrypt vars/secrets.yml

# 암호화된 상태로 내용 확인
ansible-vault view vars/secrets.yml

# 암호화된 상태로 내용 수정
ansible-vault edit vars/secrets.yml

# Vault 비밀번호 변경
ansible-vault rekey vars/secrets.yml

김개발 씨는 드디어 첫 번째 시크릿 파일을 만들어보기로 했습니다. 터미널을 열고 ansible-vault create를 입력하자, 갑자기 vim 에디터가 열렸습니다.

당황한 김개발 씨에게 박시니어 씨가 설명했습니다. "create 명령어는 처음부터 암호화된 파일을 만들 때 사용해요.

에디터에서 내용을 작성하고 저장하면, 자동으로 암호화되어 저장됩니다." create와 encrypt의 차이를 이해하는 것이 중요합니다. create는 빈 상태에서 시작하여 암호화된 파일을 새로 만드는 것입니다.

반면 encrypt는 이미 존재하는 평문 파일을 암호화하는 것입니다. 마치 빈 금고를 사서 처음부터 귀중품을 넣는 것(create)과, 책상 위에 있던 현금을 기존 금고에 옮기는 것(encrypt)의 차이와 같습니다.

실무에서는 encrypt를 더 자주 사용하게 됩니다. 왜냐하면 보통 개발 초기에는 평문으로 빠르게 테스트하다가, 나중에 Git에 커밋하기 전에 암호화하는 경우가 많기 때문입니다.

김개발 씨도 로컬에서 먼저 database.yml 파일을 만들어 테스트한 후, 잘 동작하는 것을 확인하고 ansible-vault encrypt를 실행했습니다. view 명령어는 매우 유용합니다.

암호화된 파일의 내용을 확인하고 싶을 때, decrypt로 복호화하면 평문 파일이 디스크에 남게 됩니다. 실수로 이 상태에서 커밋하면 대참사가 벌어집니다.

하지만 view를 사용하면 터미널에 내용만 출력하고, 파일은 암호화된 상태 그대로 유지됩니다. edit 명령어도 같은 원리입니다.

내용을 수정해야 할 때 decrypt로 복호화하고, 수정하고, 다시 encrypt하는 것은 번거롭고 위험합니다. edit 명령어를 사용하면 임시로 복호화하여 에디터를 열고, 저장하면 자동으로 다시 암호화됩니다.

디스크에는 항상 암호화된 파일만 남습니다. rekey는 비밀번호를 변경할 때 사용합니다.

팀원이 퇴사하거나, 정기적인 보안 점검 때문에 Vault 비밀번호를 바꿔야 할 때가 있습니다. 이때 rekey를 사용하면 기존 비밀번호로 복호화한 후, 새 비밀번호로 다시 암호화하는 과정을 한 번에 처리해줍니다.

주의할 점이 있습니다. decrypt 명령어는 가급적 사용하지 않는 것이 좋습니다.

한 번 복호화하면 평문 파일이 생기고, 이 파일을 실수로 커밋할 위험이 있습니다. 반드시 view나 edit를 사용하는 습관을 들이세요.

만약 부득이하게 decrypt를 사용했다면, 작업 후 즉시 다시 encrypt하거나 파일을 삭제해야 합니다. 김개발 씨는 이제 각 명령어의 용도를 완벽히 이해했습니다.

"view로 확인하고, edit로 수정하고, encrypt와 decrypt는 최대한 피하면 되겠네요!"

실전 팁

💡 - view와 edit를 주로 사용하고, decrypt는 특별한 경우에만 사용하세요

• EDITOR 환경 변수를 설정하면 원하는 에디터로 열 수 있습니다 (예: export EDITOR=nano)

---

3. 암호화된 변수 사용

김개발 씨는 secrets.yml 파일 전체를 암호화하는 방법을 배웠습니다. 그런데 문득 의문이 들었습니다.

"파일 전체가 아니라 특정 변수 하나만 암호화할 수는 없나요? 어떤 값은 다른 팀원이 봐도 되는데, 비밀번호만 숨기고 싶어요."

encrypt_string 명령어를 사용하면 파일 전체가 아닌 특정 변수 값만 암호화할 수 있습니다. 이를 인라인 암호화라고 부릅니다.

일반 변수와 암호화된 변수를 한 파일에 섞어 쓸 수 있어서, 가독성을 유지하면서 민감한 정보만 보호할 수 있습니다.

다음 코드를 살펴봅시다.

# 특정 값만 암호화 (결과를 복사해서 사용)
ansible-vault encrypt_string 'super_secret_123' --name 'db_password'

# 출력 결과 예시
db_password: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  61316561396134653431393037613161
  33623461353465306135626636386536

# vars/database.yml에서 혼합 사용
---
db_host: localhost           # 평문 (민감하지 않음)
db_port: 5432               # 평문
db_name: myapp_production   # 평문
db_user: app_user           # 평문
db_password: !vault |       # 암호화된 값
  $ANSIBLE_VAULT;1.1;AES256
  61316561396134653431393037613161

김개발 씨는 새로운 고민에 빠졌습니다. 데이터베이스 설정 파일에는 호스트, 포트, 데이터베이스 이름 같은 정보도 함께 있습니다.

이런 정보는 사실 민감하지 않아서 팀원 누구나 봐도 됩니다. 하지만 파일 전체를 암호화하면, 단순히 포트 번호를 확인하려고 해도 Vault 비밀번호를 입력해야 합니다.

박시니어 씨가 해결책을 알려주었습니다. "encrypt_string을 사용하면 원하는 값만 암호화할 수 있어요." encrypt_string의 동작 원리를 살펴봅시다.

이 명령어는 입력받은 문자열을 암호화하고, 그 결과를 YAML 형식으로 출력해줍니다. 출력된 결과를 복사해서 설정 파일에 붙여넣으면 됩니다.

마치 편지의 특정 단어만 암호로 바꿔 쓰는 것과 같습니다. 전체 편지는 읽을 수 있지만, 중요한 단어만 해독 키가 있어야 알 수 있습니다.

!vault 태그가 핵심입니다. YAML 파일에서 !vault로 시작하는 값은 Ansible이 자동으로 암호화된 데이터임을 인식합니다.

Playbook을 실행할 때 Vault 비밀번호를 제공하면, 이 값들이 자동으로 복호화되어 사용됩니다. 개발자가 별도로 복호화 로직을 작성할 필요가 없습니다.

이 방식의 큰 장점은 가독성입니다. 파일을 열었을 때 db_host, db_port 같은 일반 정보는 바로 확인할 수 있습니다.

어떤 서버에 연결하는지, 어떤 포트를 사용하는지 한눈에 파악됩니다. 민감한 db_password만 암호화되어 있어서, 코드 리뷰 때도 "아, 비밀번호는 안전하게 관리되고 있구나"라고 쉽게 확인할 수 있습니다.

실무에서 자주 사용하는 패턴이 있습니다. 보통 vars/main.yml에는 일반 변수를, vars/secrets.yml에는 민감한 변수만 모아둡니다.

하지만 encrypt_string을 사용하면 하나의 파일에서 모두 관리할 수도 있습니다. 어떤 방식이 더 좋은지는 팀의 선호와 상황에 따라 다릅니다.

주의할 점이 있습니다. encrypt_string으로 생성한 암호문을 복사할 때 들여쓰기를 정확히 유지해야 합니다.

YAML은 들여쓰기에 민감한 언어이기 때문에, 한 칸이라도 어긋나면 파싱 에러가 발생합니다. 또한 파이프(|) 문자 뒤에 있는 암호문 블록의 들여쓰기도 일관되게 유지해야 합니다.

김개발 씨는 encrypt_string의 유용함에 감탄했습니다. "이제 설정 파일을 보기 좋게 정리하면서도 보안을 유지할 수 있겠네요!"

실전 팁

💡 - encrypt_string 결과를 붙여넣을 때 들여쓰기를 정확히 맞추세요

• 여러 개의 시크릿을 한 번에 암호화하려면 스크립트를 만들어 자동화하면 편리합니다

---

4. Vault 비밀번호 관리

김개발 씨는 Vault를 잘 사용하고 있었습니다. 그런데 어느 날 CI/CD 파이프라인을 설정하다가 막혔습니다.

"로컬에서는 제가 비밀번호를 직접 입력하면 되는데, 자동화된 환경에서는 어떻게 비밀번호를 전달하죠?" 이것은 많은 개발자가 처음 겪는 난관입니다.

Vault 비밀번호를 관리하는 방법은 크게 세 가지입니다. 직접 입력, 파일로 제공, 스크립트로 동적 생성입니다.

로컬 개발 환경에서는 직접 입력이 편리하고, CI/CD 환경에서는 파일이나 스크립트 방식을 사용합니다. 각 방법의 장단점을 이해하고 상황에 맞게 선택해야 합니다.

다음 코드를 살펴봅시다.

# 방법 1: 실행 시 직접 입력 (가장 안전, 수동)
ansible-playbook site.yml --ask-vault-pass

# 방법 2: 파일로 비밀번호 제공
echo "my_vault_password" > ~/.vault_pass
chmod 600 ~/.vault_pass
ansible-playbook site.yml --vault-password-file ~/.vault_pass

# 방법 3: 환경 변수로 파일 경로 지정
export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass
ansible-playbook site.yml  # 자동으로 파일 사용

# 방법 4: 스크립트로 동적으로 비밀번호 획득
#!/bin/bash
# get_vault_pass.sh
aws secretsmanager get-secret-value \
  --secret-id ansible-vault-password \
  --query SecretString --output text

chmod +x get_vault_pass.sh
ansible-playbook site.yml --vault-password-file ./get_vault_pass.sh

김개발 씨의 고민은 모든 DevOps 엔지니어가 한 번쯤 겪는 문제입니다. Vault로 시크릿을 암호화했는데, 그 Vault를 여는 비밀번호는 어디에 보관해야 할까요?

이 비밀번호마저 Git에 저장하면 아무 의미가 없습니다. 박시니어 씨가 각 방법의 장단점을 설명해주었습니다.

--ask-vault-pass는 가장 안전한 방법입니다. 실행할 때마다 비밀번호를 직접 입력하므로, 비밀번호가 어디에도 저장되지 않습니다.

로컬에서 개발하거나 테스트할 때 권장되는 방식입니다. 하지만 CI/CD처럼 사람이 개입할 수 없는 환경에서는 사용할 수 없다는 단점이 있습니다.

비밀번호 파일은 자동화의 첫걸음입니다. 비밀번호를 파일에 저장하고, --vault-password-file 옵션으로 경로를 지정합니다.

중요한 것은 이 파일의 권한을 600으로 설정하여 본인만 읽을 수 있게 하는 것입니다. 또한 이 파일은 절대로 Git에 커밋하면 안 됩니다.

.gitignore에 반드시 추가해야 합니다. 환경 변수 ANSIBLE_VAULT_PASSWORD_FILE은 편의성을 높여줍니다.

매번 --vault-password-file 옵션을 붙이는 것은 번거롭습니다. 환경 변수로 설정해두면 옵션 없이도 자동으로 해당 파일을 사용합니다.

개발 환경의 .bashrc나 .zshrc에 설정해두면 편리합니다. 스크립트 방식은 가장 안전하면서도 자동화에 적합합니다.

AWS Secrets Manager, HashiCorp Vault, Azure Key Vault 같은 외부 시크릿 관리 서비스에서 비밀번호를 가져오는 스크립트를 만듭니다. 이 스크립트는 실행될 때마다 외부 서비스에서 비밀번호를 조회하므로, 로컬에 비밀번호가 저장되지 않습니다.

CI/CD 환경에서 가장 권장되는 방식입니다. 실무에서의 권장 패턴을 알려드리겠습니다.

로컬 개발 환경에서는 --ask-vault-pass나 비밀번호 파일을 사용합니다. CI/CD 환경에서는 스크립트 방식을 사용하여 AWS Secrets Manager 같은 서비스에서 비밀번호를 가져옵니다.

이렇게 하면 비밀번호가 코드 저장소에도, CI/CD 로그에도 노출되지 않습니다. 주의사항이 있습니다.

비밀번호 파일을 사용할 때는 반드시 .gitignore에 추가하세요. 또한 파일 권한을 600으로 설정하여 다른 사용자가 읽지 못하게 해야 합니다.

CI/CD 환경에서는 비밀번호가 로그에 출력되지 않도록 주의해야 합니다. 김개발 씨는 이제 상황에 맞는 비밀번호 관리 방법을 선택할 수 있게 되었습니다.

실전 팁

💡 - .vault_pass 파일은 반드시 .gitignore에 추가하세요

• CI/CD에서는 AWS Secrets Manager나 HashiCorp Vault 연동을 권장합니다

---

5. CICD에서 Vault 활용

김개발 씨는 GitHub Actions로 자동 배포 파이프라인을 구축하고 있었습니다. 로컬에서는 Vault가 잘 동작했는데, CI/CD에서는 어떻게 Vault 비밀번호를 전달해야 할지 고민이었습니다.

"GitHub Secrets에 Vault 비밀번호를 저장하면 되나요?"

CI/CD 환경에서 Ansible Vault를 사용하려면 파이프라인 시크릿 관리 기능과 연동해야 합니다. GitHub Actions의 Secrets, GitLab CI의 Variables, Jenkins의 Credentials 등을 활용하여 Vault 비밀번호를 안전하게 전달합니다.

비밀번호가 로그에 노출되지 않도록 마스킹 처리되는 것이 핵심입니다.

다음 코드를 살펴봅시다.

# .github/workflows/deploy.yml
name: Deploy with Ansible
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Ansible
        run: pip install ansible

      - name: Create vault password file
        run: echo "${{ secrets.ANSIBLE_VAULT_PASSWORD }}" > .vault_pass

      - name: Run Ansible Playbook
        run: |
          ansible-playbook -i inventory/production site.yml \
            --vault-password-file .vault_pass

      - name: Cleanup vault password
        if: always()
        run: rm -f .vault_pass

김개발 씨는 GitHub Actions를 처음 설정해보는 중이었습니다. 로컬에서 열심히 테스트한 Ansible Playbook을 자동으로 실행하고 싶었습니다.

하지만 Vault 비밀번호를 어떻게 전달해야 할지 막막했습니다. 박시니어 씨가 GitHub Secrets의 개념을 설명해주었습니다.

"GitHub Actions에는 Secrets라는 기능이 있어요. 저장소 설정에서 비밀번호를 등록해두면, 워크플로우에서 안전하게 사용할 수 있습니다.

이 값은 로그에 출력되어도 자동으로 마스킹되어 ***로 표시돼요." 워크플로우의 동작 원리를 단계별로 살펴봅시다. 먼저 코드를 체크아웃하고 Ansible을 설치합니다.

그 다음이 핵심인데, GitHub Secrets에 저장된 ANSIBLE_VAULT_PASSWORD 값을 .vault_pass 파일에 씁니다. 이 파일을 --vault-password-file 옵션으로 지정하여 Playbook을 실행합니다.

cleanup 단계가 매우 중요합니다. 작업이 끝나면 .vault_pass 파일을 반드시 삭제해야 합니다.

if: always() 조건을 붙여서, 앞선 단계가 실패하더라도 항상 삭제가 실행되도록 합니다. 이렇게 하면 비밀번호 파일이 러너에 남아 있을 위험을 줄일 수 있습니다.

GitLab CI에서도 비슷한 방식을 사용합니다. GitLab에서는 CI/CD Variables 메뉴에서 변수를 등록합니다.

Masked 옵션을 체크하면 로그에 마스킹되고, Protected 옵션을 체크하면 보호된 브랜치에서만 사용할 수 있습니다. $ANSIBLE_VAULT_PASSWORD 형태로 변수를 참조합니다.

Jenkins에서는 Credentials 플러그인을 사용합니다. Jenkins의 Credentials 메뉴에서 Secret text 타입으로 비밀번호를 등록합니다.

Pipeline에서 withCredentials 블록을 사용하여 비밀번호를 환경 변수로 주입받습니다. 마찬가지로 로그에 자동 마스킹됩니다.

보안을 더 강화하려면 어떻게 해야 할까요? AWS Secrets Manager나 HashiCorp Vault 같은 외부 서비스를 사용하는 것이 가장 좋습니다.

CI/CD 파이프라인에서 직접 해당 서비스에 접근하여 비밀번호를 가져오면, GitHub Secrets에 저장하는 것보다 더 안전합니다. 접근 로그도 남고, 비밀번호 로테이션도 쉽습니다.

주의사항을 말씀드리겠습니다. echo 명령어로 비밀번호를 파일에 쓸 때, 명령어 자체가 로그에 출력되지 않도록 주의하세요.

GitHub Actions는 secrets를 자동으로 마스킹하지만, 직접 echo로 출력하면 노출될 수 있습니다. 또한 self-hosted runner를 사용한다면, 다른 워크플로우가 임시 파일에 접근할 수 없도록 격리가 필요합니다.

김개발 씨는 무사히 CI/CD 파이프라인을 완성했습니다. 이제 main 브랜치에 푸시하면 자동으로 서버에 배포됩니다.

실전 팁

💡 - GitHub Secrets는 저장소 Settings > Secrets and variables > Actions에서 등록합니다

• if: always() 조건으로 임시 파일 삭제를 보장하세요

---

6. Vault 보안 베스트 프랙티스

김개발 씨는 Vault를 성공적으로 도입했습니다. 하지만 보안팀에서 정기 감사를 하면서 몇 가지 개선점을 지적받았습니다.

"Vault를 쓰는 것만으로는 부족해요. 어떻게 운영하느냐가 더 중요합니다." 보안 담당자의 말에 김개발 씨는 베스트 프랙티스를 정리해보기로 했습니다.

Vault를 안전하게 운영하려면 비밀번호 강도, 접근 권한 분리, 정기적인 로테이션, 로깅과 감사 등 여러 측면을 고려해야 합니다. 도구를 도입하는 것보다 올바른 프로세스를 수립하는 것이 더 중요합니다.

이번 장에서는 실무에서 적용할 수 있는 보안 베스트 프랙티스를 알아봅니다.

다음 코드를 살펴봅시다.

# 1. 강력한 비밀번호 생성 (최소 32자, 특수문자 포함)
openssl rand -base64 32 > ~/.vault_pass
chmod 600 ~/.vault_pass

# 2. 환경별로 다른 Vault 비밀번호 사용
ansible-playbook site.yml \
  --vault-id dev@~/.vault_pass_dev \
  --vault-id prod@~/.vault_pass_prod

# 3. 여러 Vault ID 파일 구조
vars/
  secrets_dev.yml    # dev ID로 암호화
  secrets_prod.yml   # prod ID로 암호화

# 4. 암호화할 때 Vault ID 지정
ansible-vault encrypt --vault-id prod@~/.vault_pass_prod vars/secrets_prod.yml

# 5. 정기적인 비밀번호 로테이션
ansible-vault rekey --vault-id prod@old_pass --new-vault-id prod@new_pass vars/secrets_prod.yml

보안팀의 지적을 받은 김개발 씨는 부끄러웠습니다. Vault를 도입했다는 사실에 안심하고, 운영 방식에는 신경을 쓰지 못했던 것입니다.

박시니어 씨와 함께 베스트 프랙티스를 정리해보기로 했습니다. 첫 번째 원칙은 강력한 비밀번호입니다.

Vault 비밀번호는 AES256 암호화의 키로 사용됩니다. 비밀번호가 약하면 암호화도 약해집니다.

최소 32자 이상, 대소문자와 숫자, 특수문자를 모두 포함해야 합니다. 사람이 기억하기 어렵다고요?

그래서 비밀번호 파일을 사용하는 것입니다. openssl rand로 무작위 비밀번호를 생성하면 됩니다.

두 번째 원칙은 환경별 분리입니다. 개발 환경과 운영 환경의 시크릿을 같은 비밀번호로 암호화하면 위험합니다.

개발팀 전체가 운영 시크릿에 접근할 수 있게 되기 때문입니다. Vault ID 기능을 사용하면 환경별로 다른 비밀번호를 사용할 수 있습니다.

dev 환경의 시크릿은 dev 비밀번호로만, prod 환경의 시크릿은 prod 비밀번호로만 열 수 있습니다. 세 번째 원칙은 정기적인 로테이션입니다.

같은 비밀번호를 영원히 사용하면 안 됩니다. 팀원이 퇴사할 때, 정기 보안 점검 시, 또는 3~6개월마다 비밀번호를 변경해야 합니다.

rekey 명령어를 사용하면 모든 암호화된 파일의 비밀번호를 한 번에 변경할 수 있습니다. 네 번째 원칙은 접근 로깅입니다.

누가 언제 Vault 비밀번호에 접근했는지 추적할 수 있어야 합니다. AWS Secrets Manager나 HashiCorp Vault 같은 서비스를 사용하면 자동으로 접근 로그가 남습니다.

문제가 발생했을 때 원인을 추적하고, 감사 요구사항을 충족할 수 있습니다. 다섯 번째 원칙은 최소 권한입니다.

운영 환경의 비밀번호는 배포 담당자와 시니어 개발자만 알아야 합니다. 주니어 개발자나 외부 협력사는 개발 환경의 비밀번호만 공유받습니다.

이것이 환경별로 Vault ID를 분리해야 하는 또 다른 이유입니다. 실수하기 쉬운 부분을 정리해드리겠습니다.

비밀번호 파일을 Git에 커밋하는 실수가 가장 흔합니다. .gitignore에 추가하고, 커밋 전에 git status를 꼭 확인하세요.

또한 CI/CD 로그에 비밀번호가 출력되지 않도록 echo 명령어 사용을 주의해야 합니다. 마지막으로, decrypt 후 다시 encrypt하는 것을 잊어버리는 실수도 많습니다.

김개발 씨는 체크리스트를 만들어 팀 위키에 공유했습니다. 이제 팀 전체가 안전하게 Vault를 운영할 수 있게 되었습니다.

실전 팁

💡 - 비밀번호 로테이션 주기를 캘린더에 등록해두세요

• pre-commit hook으로 평문 시크릿 커밋을 자동 차단하면 실수를 예방할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!