데이터베이스 보안: 접근 통제부터 복구 체계까지

데이터 자산을 보호하는 보안 통제의 범위

데이터베이스 보안은 데이터베이스 시스템과 저장 데이터를 무단 접근, 악의적인 공격, 우발적인 손실로부터 보호하는 조치와 통제를 말한다. 기업 데이터는 핵심 자산이며, 유출은 재정적 손실과 평판 훼손으로 이어질 수 있다. 개인정보보호법, GDPR 같은 규제 준수에도 직접 연결된다.

데이터가 한곳에 모일수록 공격 표면과 위협의 심각성도 커진다. 따라서 접근 제어만으로는 부족하며, 암호화·감사·취약점 관리·백업과 복구·물리적 보안·응용 프로그램 보안을 함께 다뤄야 한다.

⤢✕

공격 경로는 데이터베이스 바깥에서도 시작된다

SQL 인젝션

SQL 인젝션은 웹 애플리케이션 입력 필드에 악성 SQL 쿼리를 삽입하는 공격이다.

SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'

인증 우회, 데이터 유출과 수정, 서버 명령 실행 같은 결과로 이어질 수 있다. 2008년 Heartland Payment Systems 사례에서는 SQL 인젝션으로 1억 3천만 개의 신용카드 정보가 유출됐다.

권한 상승

일반 사용자 권한에서 출발해 관리자 권한을 얻는 공격이다. 시스템 취약점이나 구성 오류가 경로가 되며, 내부자 공격은 정상 접근처럼 보일 수 있어 탐지가 어렵다.

백엔드 경로의 데이터 유출

백업 파일과 로그 파일은 데이터베이스 본체와 별도로 노출될 수 있다. 클라우드 스토리지 구성 오류도 유출 원인이 된다. 2019년 Capital One 사례에서는 클라우드 서버 구성 오류로 1억 명 이상의 고객 정보가 유출됐다.

DoS 공격

대량 쿼리 요청이나 자원을 많이 소비하는 쿼리로 데이터베이스 리소스를 고갈시켜 서비스 중단을 유발한다. 금융 서비스와 전자상거래 사이트에서는 비즈니스 중단으로 직결될 수 있다.

권한·암호화·감사를 한 체계로 운영하기

최소 권한으로 접근을 설계한다

사용자에게 필요한 최소 권한만 부여하는 최소 권한 원칙을 적용한다. 역할 기반 접근 제어(RBAC)로 역할별 권한을 묶어 할당하고, 비밀번호 외 인증 요소를 요구하는 다중 인증(MFA)을 결합한다.

-- 역할 생성
CREATE ROLE financial_analyst;

-- 역할에 권한 부여
GRANT SELECT ON financial_data TO financial_analyst;

-- 사용자에게 역할 할당
GRANT financial_analyst TO user1;

저장·전송·필드 단위의 암호화

저장 데이터 암호화는 디스크에 있는 데이터를 보호하고, 전송 중 데이터 암호화는 SSL/TLS 통신을 보호한다. 민감한 필드만 선택적으로 보호해야 할 때는 애플리케이션 레벨 암호화를 사용한다. 이와 함께 키 생성, 저장, 교체 정책을 포함한 암호화 키 관리가 필요하다.

⤢✕

감사 기록으로 접근을 추적한다

데이터베이스 접근과 변경 사항을 기록하고, 비정상적인 쿼리 패턴을 실시간으로 모니터링한다. 감사 추적은 누가, 언제, 무엇을, 어디서, 어떻게 접근했는지 확인하는 기반이다. Oracle Audit Vault, IBM Guardium 등의 솔루션을 활용할 수 있다.

-- 테이블 접근 감사 설정
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees;

-- 특정 사용자 작업 감사
AUDIT ALL BY john;

취약점과 복구 가능성을 함께 관리한다

보안 패치와 데이터베이스 버전을 정기적으로 갱신하고, 불필요한 기능 및 서비스는 비활성화한다. 벤더의 보안 권고사항과 모범 사례를 따르며, 취약점 스캔과 침투 테스트를 주기적으로 수행한다.

백업은 정기적으로 수행하고 암호화해야 한다. 3-2-1 전략은 3개 복사본을 2가지 다른 미디어에 두고, 1개는 오프사이트에 보관하는 방식이다. 복구 계획을 마련한 뒤 정기적으로 복구 테스트를 수행한다.

# 전체 데이터베이스 백업
pg_dump dbname > backup.sql

# 암호화된 백업 생성
pg_dump dbname | gpg -c > backup.sql.gpg

데이터베이스 종류에 따라 달라지는 통제 지점

관계형 데이터베이스

Oracle, SQL Server, MySQL, PostgreSQL 같은 관계형 데이터베이스에서는 스토어드 프로시저로 간접 접근을 구성하고, 뷰(View)로 데이터 노출을 줄일 수 있다. 행 수준과 열 수준 보안도 주요 통제 수단이다.

-- 보안 정책 생성
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE dbo.fn_securitypredicate(SalesRepID) ON dbo.Sales;

NoSQL 데이터베이스

MongoDB, Cassandra, Redis 같은 NoSQL 데이터베이스는 스키마 없는 구조 때문에 데이터 검증이 어렵고, 기본 인증 메커니즘이 약한 경우가 많다. 분산 아키텍처도 보안 구성을 복잡하게 만든다.

// 역할 기반 접근 제어 설정
db.createUser({
  user: "appUser",
  pwd: "securePassword",
  roles: [{ role: "readWrite", db: "appDB" }],
});

클라우드 데이터베이스

AWS RDS, Azure SQL, Google Cloud SQL을 사용할 때는 공유 책임 모델을 이해해야 한다. 네트워크 보안 그룹과 VPC 구성, 키 관리 서비스(KMS), 서비스 계정의 최소 권한이 주요 고려 대상이다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds:Describe*",
      "Resource": "*"
    }
  ]
}

업종별 데이터 보호 방식

금융 기관은 데이터 마스킹으로 개인식별정보를 보호하고, 암호화된 연결을 강제하며 TLS 1.2 이상만 허용한다. 데이터베이스 활동 모니터링, 분기별 취약점 평가와 침투 테스트, 다중 인증 및 세분화된 접근 제어도 적용한다.

의료 기관은 HIPAA 규정 준수를 위한 암호화와 환자 데이터 접근의 엄격한 감사 추적이 필요하다. 역할 기반 접근 제어로 의료진 권한을 관리하고, 데이터 분류와 중요도별 보안 조치를 마련한다. 백업 데이터는 암호화해 오프사이트에 보관한다.

전자상거래 기업은 결제 정보 암호화를 위해 PCI DSS를 준수하고, 사용자 행동 분석으로 이상을 탐지한다. 마이크로서비스 아키텍처에서는 데이터를 격리하며, API 게이트웨이로 데이터베이스 간접 접근을 구성한다. 고객 데이터에는 익명화와 가명화를 적용한다.

보안 체계가 향하는 방향

머신러닝 기반 이상 패턴 탐지, 사용자 행동 분석을 통한 내부자 위협 식별, 자동화된 취약점 탐지와 대응, 예측 보안 분석이 보안 운영에 활용된다.

제로 트러스트 아키텍처는 "신뢰하지 말고, 항상 검증하라"는 원칙을 따른다. 네트워크 위치가 아니라 신원을 기준으로 접근을 제어하고, 세션마다 권한을 검증하며 데이터베이스 마이크로 세분화를 구현한다.

프라이버시 보호 데이터베이스 설계, 암호화된 상태에서 쿼리를 처리하는 동형 암호화, 통계 데이터를 보호하는 차등 프라이버시, 자동화된 규정 준수 확인 메커니즘도 강화되는 영역이다.

⤢✕

평가부터 운영 개선까지 이어지는 보안 체계

현재 데이터베이스 환경을 평가하고 보호할 데이터를 식별·분류한 뒤, 위험을 평가해 우선순위를 정한다. 이 결과를 바탕으로 보안 정책과 절차를 수립한다.

인증과 권한 부여, 암호화, 감사와 모니터링, 취약점 관리 프로세스를 구현한다. 운영 단계에서는 보안 패치와 업데이트를 적용하고 정기 점검과 감사를 수행하며, 인시던트 대응 계획과 직원 교육을 유지한다.

새로운 위협에 대한 대응책을 마련하고 보안 기술과 도구를 갱신해야 한다. 보안 정책을 정기적으로 검토하고 업계 모범 사례를 참고하는 과정도 지속된다. 데이터베이스 보안은 기술 구현에 그치지 않고 조직 문화와 프로세스를 포함하며, 사용 편의성과의 균형, 규제 환경 변화 대응, 내부자 위협 대응을 함께 요구하는 조직 전체 정보 보안 전략의 핵심 구성 요소다.