DB 연결 문자열(Connection String)의 평문 저장 위험

컴퓨터 화면에 구성 파일 속 강조된 데이터베이스 연결 문자열이 노출된 모습이다.

증상 확인: DB 연결 문자열이 코드나 설정 파일에 그대로 노출되어 있나요?

애플리케이션 소스 코드, 설정 파일(.config, .env, .properties), 배포 스크립트 내부에 데이터베이스의 ID, 비밀번호, 서버 주소가 평문으로 하드코딩되어 있다면, 이는 심각한 보안 위협입니다. 코드 리포지토리에 커밋된 순간부터, 서버 파일 시스템에 저장된 그 순간부터 위험에 노출됩니다.

컴퓨터 화면에 구성 파일 속 강조된 데이터베이스 연결 문자열이 노출된 모습이다.

원인 분석: 왜 평문 저장이 치명적인가

연결 문자열은 데이터베이스에 대한 완전한 접근 권한을 부여하는 ‘마스터 키’와 같습니다. 이 키가 탈취되면 공격자는 모든 데이터를 유출, 변조, 삭제할 수 있으며, 심지어 데이터베이스 서버를 장악하는 데 이용될 수 있습니다. 평문 저장의 주요 위험 경로는 다음과 같습니다.

  • 소스 코드 유출: 깃(Git) 리포지토리가 공개되거나 내부 유출 시, 모든 인증 정보가 함께 노출됨.
  • 서버 파일 접근: 애플리케이션 서버가 해킹당하거나, 불필요하게 파일 시스템 접근 권한이 열려 있을 경우 설정 파일을 직접 읽어낼 수 있음.
  • 구성 관리 실수: 개발, 스테이징, 운영 환경을 구분하지 않고 동일한 자격 증명을 사용하며, 보안 수준이 낮은 환경에서 먼저 유출될 가능성이 높음.

해결 방법 1: 환경 변수(Environment Variables) 활용

가장 널리 적용 가능하고 비교적 쉬운 첫 번째 방어선입니다. 연결 문자열 전체나 구성 요소를 운영 체제의 환경 변수에 저장하고, 애플리케이션에서 이를 참조하도록 변경합니다.

  1. 환경 변수 설정: 운영체제 수준에서 변수를 설정합니다.

    Windows(명령 프롬프트): setx DB_CONNECTION_STRING "Server=myServer;Database=myDB;User Id=myUser;Password=myPass;"

    Linux/macOS: export DB_CONNECTION_STRING="Server=myServer;Database=myDB;User Id=myUser;Password=myPass;" (영구적 설정은 ~/.bashrc 등에 추가)

  2. 애플리케이션 코드 수정: 평문 문자열 대신 환경 변수를 읽어오도록 코드를 변경합니다.

    예시 (Python): import os; connection_string = os.environ.get('DB_CONNECTION_STRING')

    예시 (C# .NET): string connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION_STRING");

  3. 주의사항: 환경 변수 자체도 프로세스 메모리에 로드되므로, 서버가 메모리 덤프 공격에 취약할 경우 유출 가능성이 있습니다. 또한, 실수로 ps aux 또는 프로세스 탐색기와 같은 명령으로 노출될 수 있으니, 다음 단계를 고려하는 것이 좋습니다.

경고: 이 방법을 적용하기 전, 기존의 평문 연결 문자열이 포함된 모든 파일(가령 .git 히스토리)에서 해당 문자열을 완전히 제거해야 합니다. 단순히 삭제 커밋만으로는 깃 히스토리에 남아 있으므로, git filter-branch 또는 BFG Repo-Cleaner 같은 도구를 사용해 히스토리를 재작성하는 것이 안전합니다.

해결 방법 2: 비밀 관리 도구(Secrets Manager) 도입

프로덕션 환경에서 체계적인 관리를 위해서는 전용 비밀 관리 서비스를 사용하는 것이 표준입니다, aws secrets manager, azure key vault, hashicorp vault 등이 대표적입니다.

  1. 비밀 저장소에 연결 문자열 저장: 관리 콘솔 또는 cli를 사용해 연결 문자열을 안전한 저장소에 등록합니다. 저장 시 자동 암호화가 적용됩니다.
  2. 애플리케이션 권한 구성: 애플리케이션이 위치한 서버(또는 서비스 계정)에 비밀 저장소로부터 ‘읽기’ 권한을 부여합니다. 이는 IAM 역할, 관리 ID, 토큰 등으로 구현됩니다.
  3. SDK를 통한 동적 조회: 애플리케이션 시작 시 또는 연결이 필요할 때마다 SDK를 호출하여 메모리 내에서만 비밀을 가져옵니다. 하드코딩된 문자열이 완전히 사라집니다.

    예시 (AWS Secrets Manager – Python):


    import boto3
    import json

    def get_secret():
      client = boto3.client('secretsmanager')
      response = client.get_secret_value(SecretId='MyDatabaseSecret')
      secret = json.loads(response['SecretString'])
      return secret['connectionString']

이 방식의 장점은 암호화 저장, 접근 로깅, 자동 로테이션(주기적 비밀번호 변경) 지원, 세분화된 권한 관리 등 전문적인 보안 기능을 제공한다는 점입니다.

해결 방법 3: 관리 ID(Managed Identity) 또는 IAM 데이터베이스 인증 사용

가장 근본적인 해결책으로, 비밀번호 자체를 없애는 접근법입니다. 클라우드 환경에서 특별히 강력한 방법입니다.

관리 ID/서비스 주체 활용

애플리케이션 서비스(예: Azure App Service. Aws ec2 instance profile)에 관리 id를 부여하고, 데이터베이스(예: azure sql database)에서 해당 id에 접근 권한을 부여합니다. 연결 문자열에서 비밀번호가 제거되고, ‘인증=Active Directory 기본’ 같은 방식으로 대체됩니다.

IAM 데이터베이스 인증 (RDS Aurora, PostgreSQL/MySQL)

AWS RDS의 경우, IAM 역할을 기반으로 데이터베이스 접근 토큰을 생성합니다. 이 토큰은 수명이 짧고(15분), 연결 문자열에 포함되어 사용됩니다. 비밀번호를 저장하거나 관리할 필요가 전혀 없습니다.

  1. 애플리케이션에 IAM 역할 할당.
  2. RDS 데이터베이스에 IAM 사용자/역할을 매핑.
  3. 애플리케이션에서 AWS SDK를 사용해 IAM 인증 토큰을 동적으로 생성하여 연결 문자열에 사용.

    연결 문자열 예: "Host=my-db.cluster-xxx.rds.amazonaws.com;Username=my_iam_role;Password=[GENERATED_TOKEN];Database=myDB"

주의사항 및 추가 보안 강화 조치

위의 방법을 적용한 후에도 안심할 수 없습니다, 보안은 다층적으로 구성됩니다.

  • 최소 권한 원칙: 연결 문자열에 사용된 데이터베이스 계정은 애플리케이션에 필요한 최소한의 권한(crud 중 필요한 것만)만 가져야 합니다. 절대 ‘sa’, ‘root’, ‘admin’ 계정을 사용하지 마십시오.
  • 네트워크 격리: 데이터베이스는 공용 인터넷에 직접 노출되어서는 안 됩니다. 프라이빗 서브넷(VPC)에 배치하고, 애플리케이션 서버와는 VPN, VPC 피어링, 보안 그룹/NSG 규칙으로만 통신하도록 제한하십시오.
  • 연결 문자열 암호화: .NET의 aspnet_regiis -pef "connectionStrings" . -prov "DataProtectionConfigurationProvider" 명령어처럼, 설정 파일 내 연결 문자열 섹션 자체를 암호화할 수 있는 기능을 활용하십시오. (단, 이는 서버 복호화 키 관리가 선행되어야 함)
  • 정기적인 감사: 비밀 관리 도구의 접근 로그, 데이터베이스 감사 로그를 모니터링하여 비정상적인 접근 시도를 탐지하십시오.

전문가 팁: 개발 생산성과 보안의 균형 잡기
로컬 개발 환경에서 매번 복잡한 비밀 관리 도구를 설정하는 것은 번거로울 수 있습니다. 이를 해결하기 위해 .env.local 또는 appsettings.Development.json 같은 로컬 전용 설정 파일을 사용하되, 이 파일은 반드시 .gitignore에 등록하여 리포지토리에 절대 커밋되지 않도록 하십시오. 팀 내에서는 .env.example 파일에 가짜 값(예: “YOUR_DB_HOST_HERE”)만 남겨두고, 새 팀원은 이를 복사하여 로컬 값을 채우는 방식을 따르게 합니다, 이렇게 하면 보안 규칙을 지키면서도 개발 효율을 유지할 수 있습니다.