1. 데이터베이스의 기본 개념
데이터베이스와 DBMS
데이터베이스(Database)는 서로 관련된 데이터를 구조화하여 저장한 집합이며, DBMS(Database Management System)는 이를 정의, 조회, 변경, 관리하는 소프트웨어이다
관계형 데이터베이스는 데이터를 행과 열로 구성된 테이블로 표현한다. 기본키는 각 행을 식별하고, 외래키는 테이블 사이의 관계를 연결한다. SQL로 데이터를 조회, 변경하며, 뷰를 통해 필요한 행과 열을 선택하여 제공할 수 있다
데이터베이스 보안에서는 접근 권한을 통제하고, 허가되지 않은 정보 조회, 변경, 삭제를 방지하는 것이 중요하다. 뷰로 일부 정보를 숨기더라도 원본 테이블의 권한이나 질의 결과를 통한 추론 가능성까지 고려해야 한다
데이터베이스 구조와 관계형 모델, 키, SQL, 뷰에 대한 자세한 내용은 데이터베이스개념에서 확인할 수 있다 🟡<- 링크 추가
2. SQL 삽입 공격의 원리와 예시
SQL 삽입 공격(SQL Injection, SQLi)
응용 프로그램이 SQL을 구성하는 과정에 악의적인 입력을 넣어, 원래 의도한 질의의 구조나 동작을 변경하는 공격이다
사용자 입력을 SQL 문자열에 직접 연결하면, 입력값이 단순한 데이터가 아니라 SQL 문법의 일부로 해석될 수 있다
공격자는 이를 이용하여 인증 조건을 우회하거나, 허용되지 않은 데이터를 조회·변경할 수 있다
2.1 공격의 경로와 영향
웹 환경에서는 일반적으로 다음 경로로 요청이 전달된다
- 사용자가 브라우저에서 값을 입력한다
- 웹 응용 프로그램이 입력값을 이용하여 SQL을 구성한다
- 데이터베이스 서버가 SQL을 실행한다
- 응용 프로그램이 결과를 이용하거나 사용자에게 반환한다
공격자는 데이터베이스에 직접 접속하지 않아도, 취약한 응용 프로그램을 통해 질의를 변경할 수 있다
| 영향 | 설명 |
|---|---|
| 정보 유출 | 개인정보·금융정보 등을 무단 조회 |
| 인증 우회 | 올바른 비밀번호 없이 로그인 |
| 데이터 변조, 삭제 | 레코드 변경, 테이블 삭제 등 |
| 운영체제 명령 실행 | DBMS 기능과 실행 권한에 따라 가능 |
| 서비스 거부 | 자원 소모나 데이터 훼손으로 서비스 방해 |
이러한 결과가 모든 환경에서 가능한 것은 아니다. 응용 프로그램의 질의 구성, DBMS 기능, 데이터베이스 계정 권한 등에 따라 영향이 달라진다
2.2 취약한 로그인 처리
다음은 입력값을 문자열로 연결하여 로그인 질의를 만드는 예시다
sql = "SELECT * FROM Users WHERE user='"
+ 입력한_아이디
+ "' AND pwd='"
+ 입력한_비밀번호
+ "'"
아이디로 me, 비밀번호로 1234를 입력하면 다음 SQL이 만들어진다
SELECT *
FROM Users
WHERE user='me' AND pwd='1234';응용 프로그램이 조회된 행이 있으면 로그인 성공으로 처리한다고 하자
정상적인 경우에는 두 조건을 모두 만족하는 계정이 있어야 로그인에 성공한다
비밀번호 비교 예시의 범위
이 코드는 SQL 삽입 원리를 설명하기 위한 취약한 예시다. 실제 비밀번호는 평문 저장·비교 대신 적절한 비밀번호 해시를 이용하여 검증해야 한다. 다만 해시를 사용하더라도 다른 입력을 SQL에 직접 연결하면 SQLi가 발생할 수 있다
2.3 항상 참인 조건을 이용한 인증 우회
아이디 입력에 다음 문자열을 넣었다고 하자
' OR 1=1 --
취약한 문자열 연결 방식에서는 다음과 같은 SQL이 만들어질 수 있다
SELECT *
FROM Users
WHERE user='' OR 1=1 -- ' AND pwd='anything';2.3.1 작은따옴표의 역할
맨 앞의 '는 응용 프로그램이 열어 둔 문자열을 끝낸다.
따라서 그 뒤의 OR 1=1은 아이디의 일부가 아니라 SQL 조건식으로 해석된다
2.3.2 항상 참인 조건의 역할
다음 조건은 항상 참이다
- 1 = 1
따라서 주석 앞까지의 조건은 다음처럼 된다
2.3.3 주석의 역할
--가 줄 주석으로 해석되는 환경에서는 뒤에 붙은 비밀번호 조건이 무시된다
결과적으로 계정 테이블의 행들이 반환될 수 있으며, 응용 프로그램이 행의 존재만 확인하면 인증이 우회될 수 있다
인증 우회가 성립하는 조건
취약한 SQL 구성이 존재하고, 주석이 의도대로 적용되며, 조회 결과가 있고, 응용 프로그램이 그 결과를 로그인 성공으로 처리해야 한다. 입력 문자열 하나가 모든 로그인 화면에서 통하는 것은 아니다
2.5 추가 질의를 이용한 데이터 삭제
입력값으로 문자열을 끝낸 뒤 추가 명령을 붙일 수도 있다
'; DROP TABLE Users; --
취약한 프로그램에서는 다음과 같은 SQL이 만들어질 수 있다
SELECT *
FROM Users
WHERE user=''; DROP TABLE Users; -- ' AND pwd='anything';| 구성 요소 | 역할 |
|---|---|
' | 기존 문자열 종료 |
; | 앞 문장 종료 및 다음 문장 구분 |
DROP TABLE Users | 사용자 테이블 삭제 명령 |
-- | 뒤에 붙는 내용 주석 처리 |
단, 실제 삭제가 실행되려면 연속된 여러 문장의 실행이 허용되고, 사용 중인 DB 계정에 테이블 삭제 권한이 있어야 한다
같은 원리로 환경에 따라 데이터 삽입·수정이나 계정 정보 변경도 시도될 수 있다
2.6 운영체제 명령 실행으로의 확대
일부 DBMS는 운영체제 명령을 실행하는 관리 기능을 제공한다
SQLi를 통해 이러한 기능을 호출할 수 있고 필요한 조건까지 충족되면, 데이터베이스 내부의 문제를 넘어 서버 운영체제에 영향을 주는 공격으로 확대될 수 있다
SQL Server의 xp_cmdshell이 이러한 기능의 예다
| 필요한 조건 | 의미 |
|---|---|
| 관련 기능 존재, 사용 가능 | DBMS에서 해당 기능을 제공하고 사용할 수 있어야 함 |
| 실행 권한 | DB 계정이 해당 기능을 호출할 수 있어야 함 |
| 운영체제 권한 | 명령 실행에 사용되는 OS 계정이 작업에 필요한 권한을 가져야 함 |
예를 들어 운영체제 계정을 생성하는 작업은 해당 OS 권한이 있어야 가능하다. 따라서 DB 관리자 권한을 확보했다는 사실과 모든 OS 작업을 할 수 있다는 사실은 구분해야 한다
2.7 SQL 삽입의 핵심 원리
앞의 예시는 다음 흐름으로 정리할 수 있다
- 응용 프로그램이 SQL과 사용자 입력을 문자열로 연결한다
- 입력값이 문자열 경계를 벗어나도록 만든다
- 조건식이나 추가 SQL 명령을 삽입한다
- 필요하면 주석으로 뒤의 정상 구문을 무효화한다
- 변경된 SQL이 응용 프로그램의 DB 계정 권한으로 실행된다
다만 모든 SQLi가 작은따옴표와 주석을 사용하는 것은 아니다. 숫자나 다른 SQL 구성 요소에 입력이 들어가는 경우도 있다
데이터와 명령의 경계
SQLi의 핵심은 특정 문자 자체가 아니라, 외부 입력이 SQL의 구조를 바꿀 수 있다는 것이다. 작은따옴표나
--만 차단하는 것으로 모든 SQLi를 방지할 수는 없다
2.8 예시별 비교
| 예시 | 변경하는 부분 | 가능한 결과 |
|---|---|---|
OR 1=1 삽입 | 검색·인증 조건 | 조건 우회 |
| 주석 삽입 | 뒤에 붙는 SQL 구문 | 비밀번호 조건 등의 무효화 |
| 추가 명령 삽입 | 실행할 문장 | 데이터 변경, 테이블 삭제 |
| DBMS 관리 기능 호출 | 서버 기능 실행 | 조건에 따라 OS 명령 실행 |
공격이 실행하는 SQL은 일반적으로 응용 프로그램이 데이터베이스에 접속할 때 사용하는 계정의 권한을 따른다. 이 계정에 과도한 권한이 있으면 피해 범위도 커질 수 있다
3. SQL 삽입 공격의 경로와 유형 및 대응 방법
3.1 SQL 삽입 공격의 입력 경로
SQLi는 로그인 입력란뿐 아니라 SQL 구성에 사용되는 다양한 입력값을 통해 발생할 수 있다
| 경로 | 설명 |
|---|---|
| 사용자 입력 | 입력 폼이나 URL 매개변수 등에 공격 문자열을 넣는다 |
| 서버 변수 | HTTP 헤더 등 외부에서 영향을 줄 수 있는 값을 악용한다 |
| 2차 삽입 | 저장된 데이터가 나중에 SQL 구성에 사용될 때 공격이 발생한다 |
| 쿠키 | 쿠키 값을 변경하여 SQL의 구조를 바꾼다 |
| 물리적 입력 | 웹 요청 이외의 입력 장치를 통해 공격 문자열을 전달한다 |
3.1.1 사용자 입력
검색어, 아이디, 게시글 내용처럼 사용자가 제공한 값이 SQL 문자열에 직접 연결되면 공격 경로가 될 수 있다
입력 화면에서 제한하더라도 공격자는 요청을 직접 구성할 수 있으므로, 브라우저 측 검사만으로는 충분하지 않다
3.1.2 서버 변수와 쿠키
응용 프로그램에서 서버 변수로 제공하는 값이라고 해서 모두 신뢰할 수 있는 것은 아니다
HTTP 헤더나 쿠키처럼 클라이언트가 제공하거나 변경할 수 있는 값도 포함될 수 있다. 이러한 값이 SQL에 직접 연결되면 입력 폼과 같은 문제가 발생한다
3.1.3 2차 삽입
2차 삽입(Second-Order Injection)
외부 입력이 일단 저장된 뒤, 나중에 다른 기능에서 SQL의 일부로 사용되면서 발생하는 삽입 공격이다
예를 들어 다음 순서로 발생할 수 있다
- 사용자가 입력한 문자열을 데이터베이스에 저장한다
- 저장 시에는 문자열이 데이터로 안전하게 처리된다
- 다른 기능이 저장된 값을 읽어 SQL 문자열에 직접 연결한다
- 저장된 문자열이 SQL 문법으로 해석되어 공격이 발생한다
저장된 데이터도 자동으로 안전해지지 않는다
데이터베이스 내부에서 읽어 온 값이라도 외부 입력에서 유래했을 수 있다. 저장 위치보다 SQL에 사용하는 방식이 중요하다
3.1.4 물리적 입력
바코드 리더기 등에서 읽은 값도 SQL 구성에 사용될 수 있다
따라서 웹 입력뿐 아니라 외부에서 들어오는 모든 데이터 경로를 고려해야 한다
3.2 SQLi 유형의 구분
SQLi는 공격 결과를 얻는 방식에 따라 다음과 같이 구분할 수 있다
| 유형 | 결과를 얻는 방법 |
|---|---|
| 인밴드(In-Band) | 공격 요청과 같은 통신 경로로 결과를 받는다 |
| 추론형(Inferential) | 응답이나 동작의 차이를 관찰하여 정보를 추론한다 |
| 아웃오브밴드(Out-of-Band) | 공격 요청과 다른 통신 경로로 정보를 받는다 |
이 구분과 개별 공격 기법은 완전히 같은 차원이 아니다. 예를 들어 주석은 여러 SQLi 유형에서 사용할 수 있는 구문 조작 기법이다
3.3 인밴드 SQL 삽입
인밴드 SQL 삽입(In-Band SQL Injection)
공격에 사용한 통신 경로를 통해 질의 결과나 공격의 효과를 직접 확인하는 방식이다
예를 들어 웹 요청으로 SQL을 삽입하고, 같은 웹 응답에 데이터베이스의 정보가 표시되는 경우다
3.3.1 항진식
항진식(Tautology)
조건식이 항상 참이 되도록 구성하는 기법이다
앞에서 살펴본 OR 1=1이 대표적인 예다. 검색 조건을 바꾸거나 인증을 우회하는 데 악용될 수 있다
3.3.2 줄 끝 주석
줄 주석을 사용하여 뒤에 붙는 정상 SQL 구문을 무시하도록 한다
예를 들어 비밀번호 조건이나 남은 작은따옴표를 주석 처리하여, 변경한 조건이 실행되도록 만들 수 있다
3.3.3 추가 질의 연결
추가 질의 연결(Piggybacked Queries)
원래 실행하려던 질의에 추가 SQL 문장을 붙여 함께 실행하도록 하는 기법이다
앞의 테이블 삭제 예시처럼 정상 질의 뒤에 데이터 변경 명령을 붙이는 방식이다
다만 DBMS와 드라이버의 설정, 실행 권한 등에 따라 실제 실행 가능 여부는 달라진다
3.4 추론형 SQL 삽입
추론형 SQL 삽입(Inferential SQL Injection)
목표 데이터가 응답에 직접 표시되지 않아도, 응답 내용이나 서버 동작을 관찰하여 정보를 알아내는 방식이다
질의 결과를 화면에 출력하지 않는다고 해서 SQLi를 통한 정보 유출이 모두 차단되는 것은 아니다
3.4.1 잘못된 질의를 이용한 정보 수집
문법적으로 잘못되거나 논리적으로 부적절한 질의를 유발하고, 오류 응답을 관찰할 수 있다
노출되는 오류에 따라 다음 정보를 알아낼 수 있다
- 데이터베이스 제품과 종류
- 테이블이나 열의 이름
- 데이터의 형식
- 내부 질의 구조
이러한 정보는 후속 공격을 준비하는 데 사용될 수 있다. 오류 메시지에 정보가 직접 드러나는 경우에는 오류 기반 기법으로도 설명할 수 있다
3.4.2 블라인드 SQL 삽입
블라인드 SQL 삽입(Blind SQL Injection)
데이터베이스에 참과 거짓을 구분하는 조건 등을 넣고, 응답 차이를 통해 조건의 결과와 데이터를 추론하는 공격이다
예를 들어 어떤 조건이 참일 때와 거짓일 때 페이지 내용이 다르게 나타난다면, 공격자는 그 차이를 반복 관찰하여 정보를 좁혀 갈 수 있다
응답 내용뿐 아니라 처리 시간의 차이도 정보가 될 수 있다
오류 메시지 숨김의 한계
상세 오류를 숨기는 것은 정보 노출을 줄이지만, 질의 구조가 변경되는 취약점 자체를 제거하지는 않는다. 화면이나 처리 시간의 차이를 이용한 추론이 가능할 수 있다
3.5 아웃오브밴드 SQL 삽입
아웃오브밴드 SQL 삽입(Out-of-Band SQL Injection)
SQL을 삽입한 요청의 응답이 아닌 별도의 통신 경로로 데이터를 전달받는 방식이다
원래 응답으로 정보를 얻기 어렵더라도, 데이터베이스 서버가 외부와 통신할 수 있고 관련 기능을 사용할 수 있다면 다른 경로로 정보가 유출될 수 있다
따라서 데이터베이스 서버의 외부 통신 범위와 사용 가능한 기능도 공격의 영향에 관여한다
3.6 SQLi 대응 방법의 분류
SQLi 대응은 크게 다음 세 범주로 나눌 수 있다
| 범주 | 목적 | 방법 |
|---|---|---|
| 방어적 코딩 | 취약한 SQL 구성을 예방 | 매개변수화 질의, 입력 검증, SQL DOM |
| 탐지 | 공격이나 취약점 식별 | 시그니처, 이상 탐지, 코드 분석 |
| 실행 시점 예방 | 실행 직전 비정상 질의 차단 | 예상 질의 모델과 실제 질의 비교 |
3.7 방어적 코딩
3.7.1 매개변수화 질의
매개변수화 질의(Parameterized Query)
SQL 구조와 입력 데이터를 분리하고, 입력값을 매개변수로 바인딩하여 전달하는 방식이다
취약한 방식은 입력을 SQL 문자열에 직접 연결한다
sql = "SELECT * FROM Users WHERE username='" + username + "'"
매개변수화 방식은 구조를 먼저 정하고 값을 별도로 전달한다
SELECT *
FROM Users
WHERE username = ?;execute(sql, [username])
입력값에 SQL처럼 보이는 문자가 있어도, 올바르게 바인딩하면 해당 위치의 데이터 값으로 처리된다
매개변수 표기는 사용하는 언어나 드라이버에 따라 ?, $1, :name 등으로 달라질 수 있다
매개변수로 처리할 수 없는 SQL 구성 요소
매개변수는 일반적으로 데이터 값을 위한 것이다. 테이블 이름, 열 이름, 정렬 방향 등을 동적으로 선택해야 한다면 허용한 값과 미리 정의한 SQL 조각을 대응시키는 방식 등을 사용해야 한다
3.7.2 입력 검증
입력값이 업무상 요구하는 형식과 범위를 만족하는지 확인한다
| 입력 | 검사 예시 |
|---|---|
| 나이 | 정수인지, 허용 범위인지 확인 |
| 날짜 | 올바른 날짜 형식과 값인지 확인 |
| 정렬 방향 | 허용된 선택지인지 확인 |
| 식별 코드 | 길이와 허용 문자 확인 |
입력 검증은 유용하지만, 특정 문자나 SQL 키워드를 차단하는 것만으로 모든 삽입을 막기는 어렵다. 값을 SQL에 안전하게 전달하는 처리와 함께 적용해야 한다
3.7.3 SQL DOM
SQL DOM(SQL Document Object Model)
SQL을 문자열로 직접 이어 붙이는 대신, 타입이 지정된 객체와 구조를 이용하여 질의를 구성하는 접근 방식이다
질의를 구조적으로 표현하여 입력 데이터가 의도하지 않은 SQL 문법으로 섞이는 것을 줄인다
다만 안전한 구성 기능을 사용하면서도 일부 구간에 원시 SQL 문자열을 직접 연결하면 취약점이 남을 수 있다
3.8 SQLi 탐지
| 탐지 방법 | 원리 | 한계 |
|---|---|---|
| 시그니처 기반 | 알려진 공격 패턴과 비교 | 변형되거나 새로운 패턴을 놓칠 수 있음 |
| 이상 기반 | 정상 요청이나 질의의 특성에서 벗어나는지 확인 | 정상 동작을 공격으로 오인할 수 있음 |
| 코드 분석 | 입력이 SQL 실행까지 전달되는 경로와 구성 방식 검사 | 동적 동작이나 복잡한 경로의 분석이 어려울 수 있음 |
탐지는 공격 징후를 파악하는 데 도움이 되지만, 안전한 질의 구성 자체를 대신하지는 않는다
3.9 실행 시점 예방
실행 시점 예방(Run-Time Prevention)
실행하려는 SQL이 예상한 질의 구조에 부합하는지 실행 시점에 검사하여, 비정상적인 구조 변경을 차단하는 방식이다
예를 들어 사용자 이름을 조회하는 질의에 예상하지 않은 추가 문장이나 조건 구조가 나타났는지 확인할 수 있다
핵심은 단순히 SQL 문법이 올바른지 검사하는 것이 아니다. SQLi로 변경된 질의도 문법적으로는 올바를 수 있으므로, 응용 프로그램이 의도한 구조인지를 확인해야 한다
3.10 피해 범위를 줄이는 보완 조치
취약점 예방과 함께 공격 성공 시의 영향을 제한할 수 있다
| 조치 | 목적 |
|---|---|
| DB 계정의 최소 권한 | 불필요한 테이블 삭제나 관리 기능 실행 제한 |
| 상세 오류 노출 제한 | 내부 구조에 관한 정보 유출 감소 |
| 불필요한 DBMS 기능 제한 | 운영체제 명령 실행 등으로의 확대 방지 |
| 외부 통신 제한 | 별도 경로를 통한 정보 유출 가능성 감소 |
| 로그 기록과 감시 | 의심스러운 요청과 질의 추적 |
이러한 조치는 방어를 보완하지만, 취약한 문자열 연결 방식을 그대로 두어도 된다는 의미는 아니다
4. 데이터베이스 접근 제어와 권한 위임 및 회수
4.1 데이터베이스 접근 제어의 목적
데이터베이스 접근 제어
사용자가 데이터베이스의 어느 부분에 어떤 작업을 수행할 수 있는지를 통제하는 기능이다
접근 제어에서는 다음 두 가지를 결정한다
| 판단 대상 | 예시 |
|---|---|
| 접근 범위 | 전체 데이터베이스, 특정 테이블, 특정 열, 뷰 |
| 허용 작업 | 조회, 삽입, 수정, 삭제, 객체 생성 |
데이터베이스에 접속할 수 있다고 해서 모든 테이블을 읽거나 수정할 수 있는 것은 아니다
4.2 접근 권한의 관리 방식
4.2.1 중앙 집중 관리
중앙 집중 관리(Centralized Administration)
소수의 특권 사용자가 접근 권한의 부여와 회수를 담당하는 방식이다
관리 기준을 일관되게 적용하기 쉽지만, 권한 변경 요청이 관리자에게 집중될 수 있다
4.2.2 소유권 기반 관리
소유권 기반 관리(Ownership-Based Administration)
테이블 등의 객체를 생성한 소유자가 해당 객체의 접근 권한을 부여하거나 회수하는 방식이다
객체의 사용 목적을 잘 아는 소유자가 권한을 관리할 수 있다
4.2.3 분산 관리
분산 관리(Decentralized Administration)
객체 소유자가 다른 사용자에게 접근 권한을 관리할 권한까지 위임할 수 있는 방식이다
권한을 받은 사용자가 다른 사용자에게 다시 권한을 부여할 수 있으므로, 권한의 전달 관계와 회수 범위를 관리해야 한다
| 방식 | 권한 관리의 중심 |
|---|---|
| 중앙 집중 관리 | 특권 관리자 |
| 소유권 기반 관리 | 객체 소유자 |
| 분산 관리 | 소유자와 권한을 위임받은 사용자 |
4.3 대표적인 SQL 접근 권한
| 권한 | 의미 |
|---|---|
| SELECT | 데이터 조회 |
| INSERT | 새로운 행 삽입 |
| UPDATE | 기존 데이터 수정 |
| DELETE | 행 삭제 |
| REFERENCES | 외래키 제약 조건에서 해당 테이블의 키 등을 참조 |
권한은 서로 구분된다. 예를 들어 SELECT를 가졌다고 해서 UPDATE까지 허용되는 것은 아니다. 또한 DELETE는 행을 삭제하는 권한이며, 테이블 자체를 제거하는 DROP TABLE과는 다르다
4.4 GRANT와 REVOKE
4.4.1 권한 부여
GRANT
사용자나 역할에 접근 권한을 부여하는 명령이다. 역할 구성원 관계의 부여에도 사용할 수 있다
다음은 Bob에게 직원 테이블의 조회 권한을 부여하는 예시다
GRANT SELECT ON Employee TO Bob;여러 권한을 함께 부여할 수도 있다
GRANT SELECT, UPDATE ON Employee TO Bob;명령을 실행하는 주체에게는 해당 권한을 부여할 자격이 있어야 한다
4.4.2 권한 회수
REVOKE
이전에 부여한 접근 권한이나 역할 구성원 관계를 회수하는 명령이다
REVOKE SELECT ON Employee FROM Bob;다만 Bob이 다른 사용자나 역할에서도 같은 권한을 받았다면, 하나의 부여 관계를 회수해도 접근 권한이 남을 수 있다
4.5 권한의 재부여
사용자가 권한을 직접 사용하는 것과 다른 사용자에게 다시 부여하는 것은 구분한다
GRANT SELECT ON Employee TO Bob
WITH GRANT OPTION;이 예시에서는 Bob에게 조회 권한과 함께 해당 권한을 다른 사용자에게 부여할 수 있는 자격을 준다
Bob은 자신이 위임받은 범위 안에서 다음과 같이 권한을 부여할 수 있다
GRANT SELECT ON Employee TO David;| 구분 | 의미 |
|---|---|
| 접근 권한 | 자신이 데이터를 조회하거나 변경할 수 있음 |
| 재부여 권한 | 다른 사용자에게 해당 권한을 부여할 수 있음 |
4.6 연쇄 권한 회수
연쇄 권한 회수(Cascading Revocation)
권한을 회수할 때 그 부여 관계에 의존하여 다른 사용자에게 전달된 권한도 함께 회수하는 처리이다
예를 들어 Ann이 Bob에게 권한을 주고, Bob이 David에게 다시 부여했다면 Bob의 권한 회수가 David에게도 영향을 줄 수 있다
하지만 권한이 여러 경로로 부여되었다면, 단순히 연결된 모든 사용자의 권한을 없애는 방식으로 판단해서는 안 된다
4.6.1 권한 부여 예시
다음은 동일한 권한이 전달된 순서다. 필요한 재부여 권한도 갖추었다고 가정한다
| 시점 | 부여 관계 |
|---|---|
| Ann → Bob | |
| Ann → Chris | |
| Bob → David | |
| David → Ellen | |
| Chris → David | |
| David → Frank | |
| Ellen → Jim |
이후 Bob이 David에게 부여한 권한을 회수한다
4.6.2 그림에 적용된 회수 결과
이 예시의 모델은 권한을 재부여한 시점에 어떤 권한 근거가 있었는지를 고려한다
| 관계 | 결과 | 이유 |
|---|---|---|
| Bob → David | 제거 | 직접 회수한 부여 관계 |
| Chris → David | 유지 | 별도의 유효한 권한 경로 |
| David → Ellen | 제거 | (t=40)에는 Bob에게 받은 권한에 의존 |
| Ellen → Jim | 제거 | Ellen의 권한에 의존 |
| David → Frank | 유지 | (t=60)에는 Chris에게 받은 권한도 존재 |
David 자신은 Chris를 통해 권한을 유지한다. 그러나 나중에 Chris에게 받은 권한이 이전 Ellen에 대한 부여를 소급하여 정당화하지 않는 모델이므로 Ellen과 Jim의 권한은 사라진다
예시 모델과 실제 DBMS의 구분
이 그림은 부여 시점과 의존 관계를 고려하는 회수 모델을 설명한다. 실제 DBMS에서 다른 권한 경로를 처리하는 방식과 연쇄 회수의 세부 동작이 항상 이 그림과 같다고 일반화하면 안 된다
4.7 CASCADE와 RESTRICT
권한 회수가 다른 부여 관계에 영향을 줄 때 다음 방식으로 처리할 수 있다
| 방식 | 의미 |
|---|---|
| CASCADE | 회수로 인해 근거를 잃는 종속 권한도 함께 회수 |
| RESTRICT | 종속 관계 때문에 문제가 생기면 회수 명령을 거부 |
다음은 연쇄 회수를 지정하는 SQL 형태의 예시다
REVOKE SELECT ON Employee FROM Bob CASCADE;이러한 구문과 지원 범위는 DBMS에 따라 다를 수 있다
4.8 데이터베이스의 역할 기반 접근 제어
앞에서 정리한 RBAC를 데이터베이스에도 적용할 수 있다
사용자별로 권한을 일일이 설정하는 대신 역할에 권한을 연결하고 사용자에게 역할을 할당한다
데이터베이스 RBAC는 다음 기능을 제공해야 한다
| 기능 | 내용 |
|---|---|
| 역할 생성과 삭제 | 필요한 직무별 역할 관리 |
| 역할 권한 정의 | 역할이 수행할 수 있는 작업 설정 |
| 사용자 역할 할당과 해제 | 직무에 따른 권한 부여와 회수 |
4.8.1 데이터베이스 사용자의 구분
| 사용자 유형 | 의미 |
|---|---|
| 응용 프로그램 소유자 | 응용 프로그램에 필요한 데이터베이스 객체를 소유한 사용자 |
| 최종 사용자 | 객체를 소유하지 않고 응용 프로그램을 통해 이용하는 사용자 |
| 관리자 | 데이터베이스의 일부 또는 전체를 관리하는 사용자 |
응용 프로그램 소유자는 객체의 소유자라는 의미이며, 반드시 전체 데이터베이스의 관리자는 아니다
4.9 SQL Server의 고정 역할 예시
고정 역할은 미리 정의된 권한 묶음이다. 다음은 자료에 소개된 역할과 주요 책임이다
4.9.1 서버 수준 역할
| 역할 | 주요 책임 |
|---|---|
| sysadmin | 서버 전반의 관리 |
| serveradmin | 서버 설정 변경과 종료 |
| setupadmin | 연결된 서버 등의 설정 관리 |
| securityadmin | 로그인과 보안 관련 권한 관리 |
| processadmin | 서버에서 실행 중인 프로세스 관리 |
| dbcreator | 데이터베이스 생성과 변경 및 삭제 |
| diskadmin | 디스크 파일 관리 |
| bulkadmin | 대량 데이터 삽입 작업 |
4.9.2 데이터베이스 수준 역할
| 역할 | 주요 책임 |
|---|---|
| db_owner | 해당 데이터베이스 전반의 관리 |
| db_accessadmin | 데이터베이스 사용자 접근 관리 |
| db_datareader | 사용자 테이블의 데이터 읽기 |
| db_datawriter | 사용자 테이블의 데이터 변경 |
| db_ddladmin | 데이터 정의 명령 수행 |
| db_securityadmin | 데이터베이스 권한과 역할 관련 관리 |
| db_backupoperator | 백업 관련 작업 |
| db_denydatareader | 데이터 읽기 거부 |
| db_denydatawriter | 데이터 변경 거부 |
이 표는 역할의 목적을 이해하기 위한 요약이다. 실제 세부 권한은 제품 버전과 설정에 따라 확인해야 한다
서버 역할과 데이터베이스 역할의 범위
sysadmin과db_owner를 같은 범위의 권한으로 이해하면 안 된다. 서버 전체를 대상으로 하는 역할과 개별 데이터베이스를 대상으로 하는 역할은 구분된다
5. 추론 공격과 탐지
추론 공격(Inference Attack)
직접 접근할 수 없는 민감한 정보를 허용된 데이터, 질의 결과, 메타데이터 등을 결합하여 알아내는 공격이다
각각의 조회가 허용되더라도, 결과를 함께 분석하면 공개하지 않으려던 정보가 드러날 수 있다
예를 들어 직원 이름과 급여를 함께 조회하는 것은 금지하면서, 별도의 뷰로 제공한 정보들을 연결하여 특정 직원의 급여를 알아내는 경우다
5.1 추론 채널
추론 채널(Inference Channel)
접근이 허용된 정보로부터 접근이 제한된 정보를 간접적으로 알아낼 수 있는 경로이다
추론에 활용되는 정보에는 다음이 포함될 수 있다
| 정보 | 활용 예시 |
|---|---|
| 일반 데이터 | 이름, 소속, 직책 등의 공개 정보 |
| 질의 결과 | 개별 조회 결과와 통계값 |
| 메타데이터 | 테이블 구조, 데이터 간 관계, 제약 조건 |
| 외부 지식 | 특정 직원의 직책이나 조직 구성에 관한 정보 |
접근 제어가 개별 질의를 허용 여부에 따라 정확히 처리하더라도, 결과의 조합이 드러내는 정보까지 통제하지 못하면 추론 채널이 남을 수 있다
5.2 분리된 뷰를 이용한 추론 예시
직원별 급여는 민감한 정보이므로, 이름과 급여를 직접 연결한 조회를 허용하지 않는다고 하자
5.2.1 원본 데이터
| 이름 | 직급 | 급여($) | 부서 |
|---|---|---|---|
| Andy | senior | 43,000 | strip |
| Calvin | junior | 35,000 | strip |
| Cathy | senior | 48,000 | strip |
5.2.2 사용자에게 제공한 두 뷰
첫 번째 뷰는 이름을 제외하고 직급과 급여를 제공한다
| 직급 | 급여($) |
|---|---|
| senior | 43,000 |
| junior | 35,000 |
| senior | 48,000 |
두 번째 뷰는 급여를 제외하고 이름과 부서를 제공한다
| 이름 | 부서 |
|---|---|
| Andy | strip |
| Calvin | strip |
| Cathy | strip |
각 뷰만 보면 직원 이름과 급여가 직접 연결되어 있지 않다. 그러나 추가 정보나 결과 간 대응 관계가 드러나면 숨기려던 연결을 복원할 수 있다
5.2.3 추론이 성립하는 조건
예를 들어 다음 사실을 알고 있다고 하자
- 첫 번째 뷰가 strip 부서의 직원들을 대상으로 한다
- Calvin이 해당 부서의 유일한 junior 직원이다
첫 번째 뷰에서 junior의 급여는 35,000이므로 다음 정보를 추론할 수 있다
하지만 senior 직원은 두 명이므로, 이 정보만으로는 Andy와 Cathy의 급여를 각각 확정할 수 없다. 추가적인 식별 정보나 대응 관계가 필요하다
행 순서만으로 결과를 연결하면 안 된다
SQL 결과의 행 순서는 명시적으로 보장되지 않으면 신뢰할 수 없다. 두 뷰의 같은 번째 행이 같은 사람이라고 가정하여 연결해서는 안 된다. 원본 그림의 완전한 결합 결과를 얻으려면 추가적인 대응 근거가 필요하다
5.3 통계 결과를 이용한 추론
추론은 개별 레코드뿐 아니라 집계 결과의 차이에서도 발생할 수 있다
예를 들어 다음 두 결과를 조회할 수 있다고 하자
| 질의 | 결과 |
|---|---|
| 부서 전체 직원의 급여 합계 | 200,000 |
| Alice를 제외한 직원의 급여 합계 | 150,000 |
두 값을 빼면 Alice의 급여를 알아낼 수 있다
각 질의는 집계값만 반환하지만, 두 결과의 조합은 개인의 민감한 값을 공개한다
이 예시는 여러 질의를 함께 고려해야 하는 이유를 보여 준다
5.4 추론 탐지의 두 접근 방식
추론 채널은 데이터베이스 설계 시점이나 질의 실행 시점에 탐지하고 제한할 수 있다
| 구분 | 설계 시점 탐지 | 질의 시점 탐지 |
|---|---|---|
| 검사 시점 | 구조와 접근 정책 설계 시 | 질의 또는 질의 묶음 처리 시 |
| 검사 대상 | 데이터 관계와 공개 범위 | 현재 질의와 관련 조회 이력 |
| 대응 | 구조나 접근 정책 변경 | 질의 거부 또는 변경 |
| 주요 부담 | 과도한 사전 제한 가능성 | 실행 중 분석 비용과 이력 관리 |
5.5 설계 시점의 추론 탐지
설계 시점 추론 탐지
데이터베이스 구조와 접근 정책을 분석하여 민감한 정보가 유도되는 경로를 미리 찾아 제거하거나 제한하는 방법이다
대응 방법에는 다음이 포함된다
- 데이터베이스 구조 변경
- 뷰가 제공하는 정보 범위 조정
- 접근 권한과 공개 정책 변경
- 함께 제공하면 위험한 정보의 조합 제한
그러나 가능한 추론을 미리 차단하려다 보면 필요한 조회까지 과도하게 제한하여 데이터의 이용 가능성이 낮아질 수 있다
5.6 질의 시점의 추론 탐지
질의 시점 추론 탐지
실행하려는 질의나 일련의 질의가 민감한 정보의 추론을 가능하게 하는지 검사하는 방법이다
처리 과정은 다음과 같다
- 사용자가 질의를 제출한다
- 현재 질의와 필요한 조회 이력 등을 분석한다
- 반환할 정보가 민감한 내용을 드러내는지 판단한다
- 문제가 발견되면 질의를 거부하거나 변경한다
예를 들어 전체 급여 합계를 이미 제공했다면, 이후 제출한 “Alice를 제외한 급여 합계” 질의가 민감한 정보를 드러내는지 검사할 수 있다
단일 질의 검사만으로는 부족할 수 있다
현재 질의만 보면 안전하더라도 과거 결과와 결합하면 민감한 정보가 드러날 수 있다. 따라서 질의 간 관계와 이미 공개한 정보를 고려해야 한다
5.7 추론 탐지의 어려움
두 접근 방식 모두 추론 가능성을 판단하는 알고리즘이 필요하다
특히 다음 요소 때문에 탐지가 복잡해질 수 있다
| 요소 | 어려운 이유 |
|---|---|
| 여러 질의의 조합 | 개별 결과는 안전해도 결합하면 정보가 드러날 수 있음 |
| 외부 지식 | 시스템이 사용자가 아는 모든 정보를 파악하기 어려움 |
| 데이터와 정책의 변화 | 이전에 안전했던 공개 범위가 위험해질 수 있음 |
| 이용 가능성과의 균형 | 제한이 지나치면 정상적인 분석도 어려워짐 |
다단계 보안 데이터베이스와 통계 데이터베이스에서는 이러한 문제를 다루기 위한 구체적인 추론 탐지 기법이 연구되어 왔다
5.8 SQLi와 추론 공격의 차이
| 비교 항목 | SQL 삽입 공격 | 추론 공격 |
|---|---|---|
| 핵심 원리 | 입력으로 SQL 구조를 변경 | 얻은 정보를 결합하여 비밀을 유도 |
| 질의의 성격 | 의도하지 않은 SQL 실행 | 정상적으로 허용된 질의일 수도 있음 |
| 주요 대응 | 안전한 질의 구성 | 공개 정보의 조합과 추론 채널 통제 |
블라인드 SQLi도 결과를 추론하지만, SQL 삽입 취약점을 이용한다는 전제가 있다. 여기서 다루는 데이터베이스 추론 공격은 SQLi 없이도 발생할 수 있다
6. 데이터베이스 암호화
6.1 데이터베이스 암호화의 목적
데이터베이스 암호화(Database Encryption)
데이터베이스의 전체 또는 일부를 암호문으로 저장하여, 적절한 복호화 키 없이 데이터 내용을 알아보기 어렵게 만드는 보호 방법이다
데이터베이스에는 조직의 중요한 정보가 집중되어 있으므로 여러 보안 계층을 함께 적용한다
| 보호 수단 | 주요 역할 |
|---|---|
| 방화벽 | 허용되지 않은 네트워크 접근 제한 |
| 사용자 인증 | 접근 주체의 신원 확인 |
| 시스템 접근 제어 | 운영체제 자원 등에 대한 접근 제한 |
| 데이터베이스 접근 제어 | 테이블과 작업별 권한 통제 |
| 데이터베이스 암호화 | 키가 없는 주체로부터 데이터 내용 보호 |
암호화는 다른 접근 통제가 우회되어 저장 데이터가 유출되는 상황에 대비하는 추가 방어선이 될 수 있다
6.2 암호화의 적용 범위
암호화는 필요한 보호 범위에 따라 서로 다른 단위로 적용할 수 있다
| 적용 단위 | 설명 | 예시 |
|---|---|---|
| 전체 데이터베이스 | 데이터베이스 전체를 대상으로 보호 | 저장된 데이터베이스 파일 암호화 |
| 레코드 | 특정 행을 단위로 보호 | 특정 고객의 레코드 암호화 |
| 속성 | 특정 열을 대상으로 보호 | 급여 열 암호화 |
| 개별 필드 값 | 특정 행의 특정 값을 보호 | 한 고객의 계좌번호 암호화 |
보호 단위를 세분화하면 민감한 정보만 선택적으로 암호화할 수 있지만, 키와 처리 절차의 관리가 복잡해질 수 있다
6.3 암호화와 접근 제어의 관계
접근 제어와 암호화는 서로 다른 역할을 한다
| 구분 | 접근 제어 | 암호화 |
|---|---|---|
| 핵심 질문 | 누가 어떤 작업을 할 수 있는가? | 키 없이 내용을 알아볼 수 있는가? |
| 보호 방법 | 요청을 검사하여 허용하거나 거부 | 평문을 암호문으로 변환 |
| 주요 관리 대상 | 사용자와 권한 및 정책 | 키와 암호화 데이터 |
암호화만으로 SQLi가 방지되지는 않는다
응용 프로그램이나 DBMS가 정상적으로 복호화할 수 있는 데이터를 공격자가 취약한 질의로 조회하면, 평문이 노출될 수 있다. 암호화와 안전한 질의 구성 및 접근 제어를 함께 적용해야 한다.
따라서 암호화를 평가할 때는 어디에서 복호화하고 누가 키를 사용할 수 있는지도 확인해야 한다
6.4 암호화의 주요 한계
6.4.1 키 관리
허가된 사용자는 필요한 데이터를 복호화할 수 있어야 하고, 허가되지 않은 사용자는 키를 사용할 수 없어야 한다
이를 위해 다음 사항을 관리해야 한다
- 키의 생성과 보관
- 키 사용 권한
- 필요한 주체에 대한 안전한 키 제공
- 키 변경과 복구
사용자가 반드시 키 원문을 직접 보유해야 하는 것은 아니다. 신뢰할 수 있는 구성 요소가 권한을 확인한 뒤 복호화를 대신 수행할 수도 있다
암호문과 키의 보호
데이터가 암호화되어 있어도 공격자가 복호화 키까지 확보하면 내용을 읽을 수 있다. 반대로 키를 잃으면 정상 사용자도 데이터를 복구하지 못할 수 있으므로, 키의 기밀성과 복구 가능성을 함께 관리해야 한다
6.4.2 검색과 처리의 어려움
데이터가 암호화되면 기존의 검색과 연산을 그대로 수행하기 어려울 수 있다
| 작업 | 어려움 |
|---|---|
| 값 일치 검색 | 평문 검색값과 암호문을 직접 비교하기 어려움 |
| 범위 검색 | 암호문에서 원래 값의 대소 관계를 알기 어려움 |
| 정렬 | 암호문 순서가 평문 순서와 일치하지 않을 수 있음 |
| 집계 | 암호문에 일반 산술 연산을 적용해도 원하는 결과가 나오지 않음 |
이러한 제약은 암호화 방식과 적용 위치에 따라 달라진다. 예를 들어 저장 계층에서 복호화하는 방식은 응용 프로그램의 질의를 그대로 지원할 수 있지만, 실행 중에는 DBMS가 평문을 처리한다
6.5 암호화 데이터베이스 구성 예시
다음은 서버에 암호문을 저장하고 클라이언트에서 질의 변환과 복호화를 수행하는 구성이다
모든 데이터베이스 암호화가 이 구조를 사용하는 것은 아니다
6.5.1 데이터 소유자
데이터 소유자(Data Owner)
데이터를 생성하고, 정해진 범위 안에서 이용할 수 있도록 제공하는 주체이다
데이터 소유자는 서버에 암호화된 데이터를 제공하고, 클라이언트의 질의 처리에 필요한 메타데이터를 제공한다
6.5.2 사용자
사용자는 시스템에 질의를 제출하고 결과를 이용한다
여기서 사용자는 사람, 클라이언트는 사용자의 요청을 처리하는 소프트웨어 구성 요소로 구분한다
6.5.3 클라이언트
클라이언트(Client)
사용자 질의를 서버의 암호화된 데이터에 적용할 수 있는 질의로 변환하고, 반환된 암호문을 복호화하는 전단 구성 요소이다
| 구성 요소 | 역할 |
|---|---|
| 질의 처리기 | 원래 질의를 해석하고 서버용 질의로 변환 |
| 메타데이터 | 데이터 구조와 질의 변환에 필요한 정보 제공 |
| 암호화 및 복호화 기능 | 데이터를 암호화하거나 결과를 복호화 |
6.5.4 서버
서버는 데이터 소유자로부터 받은 암호화된 데이터베이스를 저장하고, 클라이언트가 보낸 변환 질의를 실행한다
서버의 질의 실행기는 처리 결과를 암호문 형태로 클라이언트에 반환한다
6.6 질의 처리 과정
6.6.1 원래 질의 제출
사용자가 원하는 데이터를 조회하는 질의를 클라이언트에 제출한다
예를 들어 특정 고객의 계좌 정보를 요청할 수 있다
6.6.2 질의 변환과 전송
클라이언트는 메타데이터와 필요한 암호 기능을 이용하여 질의를 변환하고 서버에 보낸다
이 과정은 질의 문자열 전체를 무조건 암호화한다는 뜻이 아니다. 서버가 지원하는 암호문 검색 방식에 맞게 조건이나 표현을 바꾸는 과정이다
6.6.3 암호화된 결과 반환
서버는 변환된 질의를 암호화된 데이터베이스에 적용하고, 암호화된 결과를 클라이언트에 반환한다
어떤 검색과 연산이 가능한지는 해당 구성에서 사용하는 암호화 방식과 검색 지원 구조에 따라 달라진다
6.6.4 결과 복호화
클라이언트는 반환된 결과를 복호화하고, 필요한 후처리를 수행하여 사용자에게 평문 결과를 제공한다
| 단계 | 방향 | 전달 내용 |
|---|---|---|
| 1 | 사용자 → 클라이언트 | 원래 질의 |
| 2 | 클라이언트 → 서버 | 변환된 질의 |
| 3 | 서버 → 클라이언트 | 암호화된 결과 |
| 4 | 클라이언트 → 사용자 | 평문 결과 |
6.7 구성 예시의 보호 범위
이 구성에서는 서버에 암호문을 저장하고, 복호화 처리를 클라이언트에서 수행하도록 역할을 나눈다
그러나 서버가 암호문을 보관한다는 사실만으로 모든 정보가 숨겨지는 것은 아니다
| 고려 사항 | 의미 |
|---|---|
| 클라이언트 보호 | 복호화 기능과 평문 결과가 있는 위치를 보호해야 함 |
| 키 사용 권한 | 허가된 요청만 복호화하도록 통제해야 함 |
| 메타데이터 보호 | 구조나 분류 정보도 민감할 수 있음 |
| 검색 과정의 정보 노출 | 방식에 따라 검색 패턴이나 값의 관계가 드러날 수 있음 |
암호화는 기밀성 보호에 기여하지만, 데이터 변조 탐지나 결과의 정확성까지 자동으로 보장하지는 않는다. 필요한 경우 별도의 무결성 보호도 고려해야 한다