대상 OS: Ubuntu Server 24.04 LTS

서버에서 비밀값(토큰, API 키, DB 비밀번호, 인증서 프라이빗 키)을 “완벽하게 숨기는” 건 현실적으로 어렵습니다. 대신 목표는 (1) 노출 가능성을 줄이고, (2) 노출되더라도 피해를 제한하는 것입니다. 아래는 운영 현장에서 바로 적용 가능한 ‘최소 규칙’입니다.

비밀값 노출을 줄이는 최소 규칙(바로 적용용)

  1. 1) 비밀값은 코드/이미지에 박지 말고 “파일/환경”으로 분리

    Git 저장소, 도커 이미지, CI 로그에 한 번 들어가면 회수가 어렵습니다. 최소한 서버 파일로 분리하세요.

    # 예: 애플리케이션 전용 디렉토리
sudo install -d -m 0750 -o root -g app /etc/myapp

# 예: 시크릿 파일 생성(권한 최소화)
sudo install -m 0640 -o root -g app /dev/null /etc/myapp/secrets.env

# 내용 편집(에디터)
sudoedit /etc/myapp/secrets.env

# 예시 내용
# DB_PASSWORD='...'
# API_TOKEN='...'


  2. 2) 파일 권한/소유권을 ‘최소 접근’으로 고정

    비밀값 파일의 권한이 느슨하면, 내부 침해/실수로 유출이 쉬워집니다.

    # 소유권/권한 점검
sudo ls -al /etc/myapp/secrets.env

# 권한 강화(예: root:app, 0640)
sudo chown root:app /etc/myapp/secrets.env
sudo chmod 0640 /etc/myapp/secrets.env

# 디렉토리도 접근 최소화
sudo chmod 0750 /etc/myapp


  3. 3) systemd 서비스에는 EnvironmentFile로 주입(프로세스 인자에 노출 금지)

    비밀값을 커맨드라인 인자로 넘기면 ps로 노출되기 쉽습니다. systemd의 EnvironmentFile을 활용하면 운영이 깔끔해집니다.

    # 서비스 드롭인 생성
sudo systemctl edit myapp.service

# 아래 내용 추가
# [Service]
# EnvironmentFile=/etc/myapp/secrets.env

# 반영
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
sudo systemctl status myapp.service --no-pager


  4. 4) 로그에 비밀값이 찍히지 않게 “마스킹”과 “레벨”을 강제

    노출은 종종 “파일 유출”이 아니라 “로그/에러 메시지”에서 발생합니다. 토큰을 그대로 출력하는 코드는 반드시 고치고, 운영 로그 레벨도 점검하세요.

    # 최근 24시간 내 토큰/키 패턴 검색(예: Bearer, API_KEY 등)
# 실제 키워드는 환경에 맞게 추가
sudo journalctl --since "24 hours ago" --no-pager | rg -n "Bearer |API[_-]?KEY|TOKEN|SECRET|Authorization:" || true

# 애플리케이션 로그 파일도 점검
sudo rg -n "Bearer |API[_-]?KEY|TOKEN|SECRET|Authorization:" /var/log 2>/dev/null | head -n 50


  5. 5) “회수/회전(rotate)” 가능한 형태로 발급하고, 주기/절차를 문서화

    언젠가 노출된다고 가정하면, 회전이 쉬워야 합니다. 장기 고정 키는 결국 사고로 이어집니다.

    # (절차 예시) 교체 전/후 체크리스트를 파일로 남기기
sudo install -d -m 0750 -o root -g root /etc/myapp/runbooks
sudo tee /etc/myapp/runbooks/secret-rotation.md >/dev/null