OS UMASK와 DBMS UMASK의 상관관계

보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

OS UMASK와 DBMS UMASK의 상관관계

2021.08.04

30,534

01. 개요

1) UMASK 개념

Linux/Unix 계열에서 모든 파일과 디렉터리에는 소유권과 권한이 존재한다. 소유권은 소유자(Owner)와 소유 그룹(Group), 기타 사용자(Other)로 분류되고, 권한은 읽기(Read), 쓰기(Write), 실행(Execute) 작업에 대한 수행 권한이 있다. 소유권에 대한 권한을 지정해 주는 것이 UMASK의 기능이고 UMASK의 설정에 따라 파일 및 디렉터리는 생성 시 자동적으로 각 사용자에 지정된 소유권과 권한을 부여 받는다.

여기서 권한은 두 가지 방법으로 표기할 수 있는데 한 가지 방법은 8진법 표기이고, 다른 한 가지 방법은 심볼릭으로 표현할 수 있다. 8진법으로 읽기, 쓰기, 실행 권한을 표기할 땐 8진법의 권한을 더하여(4+2+1) 7로 표기한다. 같은 권한을 심볼릭으로 표기하면 rwx로 표현 가능하다. 심볼릭에서 제외된 권한은 -(줄표)로 표기한다.

표기법	읽기(Read)	쓰기(Write)	실행(Execute)	부여 권한	표기
8진법	4 (2^2)	2 (2^1)	1 (2^0)	읽기+쓰기+실행	7
				읽기+쓰기	6
				읽기	4
심볼릭	r	w	x	읽기+쓰기+실행	rwx
				읽기+쓰기	rw-
				읽기	r--

[표 1] 권한의 표기 방식

소유권에 부여된 권한 표기는 소유자, 소유 그룹, 기타 사용자 순으로 차례대로 나열한다. 예시로 소유자와 소유 그룹에겐 읽기와 쓰기 권한을 부여하고 기타 사용자에겐 모든 권한을 제한하도록 표시하면 8진법은 660, 심볼릭은 rw-rw---- 가 된다.

표기법	소유자(Owner)	소유 그룹(Group)	기타 사용자(Other)	전체 표기 예
8진법	6	6	0	660
심볼릭	rw-	rw-	---	rw-rw----

[표 2] 소유권에 부여된 권한 표기법 예시

UMASK에서 주의해야 할 요인은 UMASK는 권한을 허가할 때 사용하는 것이 아니고 권한을 제한할 때 사용하는 기능이다. 예를 들어 UMASK를 8진법을 사용해 022로 지정한다면 소유 그룹과 기타 사용자에게 읽기 기능을 부여하는 것이 아니라 제한한다. 파일의 최대 권한은 666, 디렉터리는 777인데 최대 권한에서 UMASK를 제거한 값이 최종적으로 설정되는 권한이다.

설정	적용 결과(8진법 사용)
UMASK 값	000	002	022
디렉터리 권한	777	775	755
파일 권한	666	664	644

[표 3] UMASK 값에 따른 디렉터리와 파일 권한(8진법 사용)

파일과 디렉터리 생성 시 사용자에게 적용된 UMASK 값이 항상 영향을 주기 때문에 시스템과 서비스 운영에 있어서 UMASK는 필수 요소다. UMASK 설정이 미흡하게 관리될 경우 시스템 내 신규 파일에 과도한 권한이 부여될 수 있고, 이로 인해 임의의 비인가자가 중요 파일에 접근할 수 있다. 시스템의 설정 파일은 소유자만 관리할 수 있어야 한다.

만약 설정 파일 생성 시 사용된 계정 UMASK에 기타 사용자의 읽기, 쓰기 권한이 제거되지 않으면 비인가자가 중요 설정 파일을 임의로 변조하거나 제거하여 시스템에 치명적인 피해를 입힐 수 있다. 생성되는 파일에 대해 비인가자의 접근을 제한하기 위해서는 UMASK를 이용해 과도한 권한이 부여되지 않도록 관리해야 한다.

2) UMASK 점검

‘2021 주요정보통신기반시설 기술적 취약점 분석ㆍ평가 방법 상세 가이드’에 UMASK로 인한 보안 피해를 예방하기 위한 기술적 방안이 Unix 계열 서버와 DBMS에 제시되어 있다.

설정	점검항목	중요도	코드
Unix 계열 서버	UMASK 설정 관리	중	U-56
Unix 계열 서버	• 시스템 UMASK 값이 022 이상인지 점검
DBMS	데이터베이스의 주요 파일 보호 등을 위해 DB계정의 UMASK를 022 이상으로 설정하여 사용	하	D-16
DBMS	• 사용자 계정의 UMASK 설정이 022 이상인지 점검

[표 4] ‘2021 주요정보통신기반시설 기술적 취약점 분석ㆍ평가 방법 상세가이드’의 UMASK 점검 항목

Unix 서버와 DBMS의 점검 방법을 살펴보면 두 항목 모두 사용자 계정의 UMASK를 확인하고 있다. Unix 서버의 경우 모든 사용자의 UMASK를 확인하기 위해 시스템의 UMASK 설정을 보고 있고, DBMS는 DBMS 서비스를 사용하는 계정에 대해서만 UMASK를 점검한다. 하지만 DBMS들 중에서는 자체적으로 UMASK를 설정할 수 있는 DBMS가 존재한다. MySQL, MariaDB, MongoDB의 경우 서비스 설정 파일을 통해 UMASK를 설정할 수 있지만, 보안 진단 시 해당 부분이 고려되지 않고 누락되는 경우가 발생한다. 정확한 UMASK 점검 및 관리를 위해서는 시스템 OS UMASK와 DB UMASK와의 상관관계를 파악해야 한다.

02. 기술 요소

1) OS UMASK

먼저 OS에서 UMASK가 적용되는 과정과 사용법을 알아보고자 한다. UMASK는 쉘(Sell) 환경 파일을 이용해 시스템 전체에 선언할 수도 있고 사용자 계정 별로 설정할 수도 있다. 하지만 가장 먼저 UMASK가 정해지는 순간은 계정이 생성되는 순간이다. 계정이 생성될 때 /etc/login.defs 파일에 선언된 UMASK 값을 상속받은 후 로그인 여부와 계정 별 환경 파일 존재 유무에 따라서 변경된다. 아래에서는 계정이 생성된 이후 UMASK를 설정하는 방법을 ‘umask’ 명령어를 이용한 과정과 쉘 환경 파일(Bash Shell 사용)을 활용한 과정으로 나눠 설명할 것이다.

① UMASK 명령어 사용 방법

시스템 명령어인 ‘umask’를 통해 손쉽게 UMASK를 설정할 수 있다. ‘umask’ 명령어만 입력했을 경우 현재 사용자 계정에 적용된 UMASK 값을 보여주지만, ‘umask’ 명령어 다음 권한을 같이 입력하면 사용자 계정의 UMASK가 입력한 권한으로 수정된다. 하지만 해당 방법은 일시적으로 적용되는 설정으로 로그아웃을 하거나 새로 터미널에 연결하면 적용되지 않으므로 권고하지 않는다.

순서	방법 및 결과 이미지
①	‘umask’ 명령어로 접속한 계정의 UMASK값 확인
①
②	‘umask 002’ 명령어로 기타 사용자의 쓰기 권한만 제한하도록 변경
②

[표 5] ‘umask’ 명령어를 사용한 권한 확인 및 변경

2) 쉘 환경 파일 활용 방법 (Bash Shell 사용)

Linux/Unix 환경 파일은 쉘 모드(Shell Mode)에 따라 적용되는데 가장 많이 사용되는 두 유형인 대화형 로그인(Login, Interactive) 모드와 대화형 비로그인(Non-Login, Interactive) 모드가 존재한다. 쉘 모드에 따라 환경 파일에 적용되는 파일의 종류와 순서, 과정이 상이하여 적용하고자 하는 사용자 계정이 어떤 쉘 모드에서 접속되는지를 고려해야 한다.

모 드

구 분

설 명

예 시

대화형

로그인

/etc/passwd 에 등록된 계정으로 자격증명 후

로그인 성공 시

• SSH 접속

• GUI에서 직접 로그인

비로그인

그래픽 환경 내의 콘솔이나 터미널,

또는 xterm과 같은 터미널 프로그램으로 접속 시

• SSH 접속 후 bash 실행

• GUI에서 터미널 생성

[표 6] 대화형 로그인 모드와 대화형 비로그인 모드 비교

먼저 Bash Shell을 사용하면서 대화형 로그인 모드일 때 사용되는 환경 파일과 과정을 알아보고자 한다. 대화형 로그인 모드일 경우 [그림 1]과 같은 흐름으로 환경 파일의 유무를 확인한 뒤 순차적으로 파일이 호출된다. 로그인에 성공하면 /etc/profile이 가장 먼저 실행되며 ~/.bash_profile을 호출한다. 이때, ~/.bash_profile이 없으면 ~/.bash_login 파일을 호출하고, ~/.bash_login도 없으면 ~/.profile을 호출한다. 그리고 ~/.bashrc와 /etc/bashrc 파일이 차례대로 실행된다.

[그림 1] 대화형 로그인 모드 환경 파일 순서도

순 서	환경 파일	설 명
①	/etc/profile	• 로그인 후 가장 먼저 실행되는 환경 파일 • 모든 시스템 사용자의 환경 및 시작 프로그램 적용
②	~/.bash_profile	• 사용자 별 환경 및 시작 프로그램 구성을 저장
	~/.bash_login	• 로그인할 때만 실행 • ~/bash.profile이 없으면 실행
	~/.profile	• ~/bash_profile, ~/bash_login이 없으면 실행
③	~/.bashrc	• 사용자 별 별칭 및 함수를 저장
④	/etc/bashrc	• 모든 시스템 사용자에게 별칭 및 함수를 저장

[표 7] bash 쉘 환경 파일 적용 순서

/etc/profile은 로그인하고 가장 먼저 실행되는 환경 파일이며 로그인할 때 반드시 사용되는 파일이기도 하다. /etc/profile의 기본 설정은 유저 아이디(UID)가 199 초과면서 유저명과 그룹명이 동일하면 시스템 계정으로 판단하고 UMASK를 002로 선언하고, 그 외 일반 계정일 경우에는 022로 설정해 준다. 새로 생성된 계정은 /etc/login.defs의 UMASK가 기본 값으로 설정되지만 로그인 과정을 거쳐 /etc/profile에 선언된 UMASK 값으로 변경된다.

[그림 2] /etc/profile에서 UMASK 설정

/etc/profile에서 시스템 계정과 일반 계정의 UMASK 선언된 후에, ~/.bash_profile부터 /etc/bashrc 파일까지 모든 환경 파일 안에 UMASK를 새로 선언할 수 있다. UMASK는 선언되는 위치에 따라서 다음에 호출되는 파일에 의해 덮어씌워질 수 있다. 해당 과정을 [표 8] 환경에서 확인해보려고 한다.

구 분	버전 정보
OS	CentOS Linux release 7.9.2009 (Core)
Bash Shell	GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)

[표 8] UMASK 테스트 환경 버전 정보

테스트는 Bash Shell을 사용 중인 root 계정으로 로그인하여 진행했다. 각 환경 파일 안에 UMASK를 다음 순서의 환경 파일 호출 전후에 배치하여 최종적으로 적용되는 값이 무엇인지 파악하려 한다.

가장 먼저 ① /etc/profile에서는 기본 설정을 변경하지 않은 상태로 시작한다.

순 서

환경 파일

선언 위치

설정 값

최종 적용 값

①

/etc/profile

로그인 상태 시,

일반 계정의 UMASK를 설정하는 조건문 내부

022

[표 9] 환경 파일 UMASK 테스트 결과 1

[그림 3] /etc/profile의 UMASK 설정

다음으로 순서 ② ~/.bash_profile이 호출되고 그 안에 순서 ③ ~/.bashrc가 다시 호출된다. ② ~/.bash_profile에서 UMASK는 ~/.bashrc 호출 전에는 200으로, 호출 후에는 002로 설정한다. 다음 순서 ③ ~/.bashrc에서 222로 선언하고 ④ /etc/bashrc에서는 UMASK 설정을 하지 않았다.

순 서	환경 파일	선언 위치	설정 값	최종 적용 값
②	~/.bash_profile	③ ~/.bashrc 호출 전	200	002
②	~/.bash_profile	③ ~/.bashrc 호출 후	002
③	~/.bashrc	④ /etc/bashrc 호출 전	222
④	/etc/bashrc	(none)	(none)

[표 10] 환경 파일 UMASK 테스트 결과 2

[그림 4] ~/.bash_profile UMASK 설정

[그림 5] ~/.bashrc UMASK 설정

테스트 결과 UMASK는 가장 마지막에 선언된 설정이 최종적으로 적용되는 것을 확인할 수 있었다. 또한 대화형 로그인 모드뿐만 아니라 대화형 비로그인 모드와 Bash Shell이 아닌 다른 Shell 일 때도 동일하게 마지막으로 선언된 UMASK가 적용된다. Bash Shell의 대화형 비로그인 모드일 경우엔 /etc/bashrc, ./~bashrc 순으로 환경 파일이 실행되며, Bash Shell 외 다른 Shell에 대한 환경 파일 실행 순서는 [표 11]를 따른다.

Shell	환경 파일 실행 순서	설 명
sh	① /etc/profile ② ~/.profile	• /etc/profile, ~/.profile는 로그인 쉘일 경우 호출
ksh	① /etc/profile ② ~/.profile ③ ~/.kshrc	• /etc/profile, ~/.profile는 로그인 쉘일 경우 호출
csh	① ~/.cshrc	• ~/.cshrc는 항상 실행
tsh	① /etc/csh.cshrc ② ~/.tcshrc ③ ~/.cshrc	• /etc/csh.cshrc, ~/.tcshrc는 항상 실행 • ~/.cshrc는 ~/.tcshrc 없을 경우 호출
zsh	① /etc/zshenv ② ~/.zshenv ③ ~/.zprofile ④ ~/.zshrc	• ~/.zprofile는 로그인 쉘일 경우 호출

[표 11] Bash Shell 외 Shell의 환경 파일 실행 순서

OS UMASK의 적용 과정과 사용법을 알아보았다. 최종적으로 적용된 UMASK 값은 ‘umask’ 시스템 명령어로 간단하게 확인할 수 있고, 앞으로 본 문서에서 OS UMASK는 해당 과정을 거친 후 적용된 UMASK 값을 의미한다.

3) DBMS UMASK

MySQL, MariaDB, MongoDB는 자체적으로 설정 파일 안에 UMASK 관련 태그를 이용하여 UMASK를 설정할 수 있다. 하지만 데이터베이스의 UMASK 점검 시 OS UMASK와 DBMS UMASK의 상관관계가 고려되지 않은 채 서비스 계정의 UMASK 설정만 확인하는 경우가 발생한다. OS UMASK와 DBMS UMASK 설정이 동시에 가능한 데이터베이스도 있기 때문에 두 설정 간에 연관성을 분석해야 한다.

03. OS UMASK와 DBMS UMAK 상관관계 분석

DBMS UMASK와 OS UMASK의 상관관계를 알아보려 한다. UMASK 설정 방법과 영향을 받는 대상 및 계정에 대한 명칭과 설명은 [표 12]와 같이 정의했다. 각 명칭은 데이터베이스에 대한 분석을 용이하게 설명하기 위해 정의했으며 사전적인 의미와 다를 수 있다.

분류	명칭	설명	예시
UMASK 설정 방법	‘OS_Umask’	OS System의 UMASK 설정을 의미	/etc/profile에 설정된 UMASK
UMASK 설정 방법	‘DB_Umask’	데이터베이스 내의 자체 설정을 의미	mysqld.service에 설정된 UMASK 태그
Output File	‘Data_File’	데이터베이스에서 생성된 데이터 파일	데이터베이스, 테이블, 테이블스페이스
Output File	‘Export_File’	데이터베이스 외부로 내보낸 파일	export한 덤프 파일, 쿼리 결과를 txt 로 저장한 파일
계정	시스템 접속 계정	시스템에 접속한 계정	OS에 초기 로그인한 계정. su -l oracle로 재접속한 계정
계정	서비스 구동 계정	서비스 프로세스를 구동한 계정	ps –ef \| grep mongod로 확인한 프로세스 구동 계정

[표 12] 데이터베이스 분석을 위한 명칭 정의

7개의 데이터베이스를 UMASK 적용 우선순위에 따라서 5가지 케이스로 분류하였다. 케이스 별로 ‘OS_Umask’와 ‘DB_Umask’가 어떻게 설정되는지, 해당 UMASK 설정에 영향을 받는 대상은 무엇인지 확인 후 그에 따른 점검 가이드를 제시할 예정이다. 추가로 모든 데이터베이스의 테스트는 OS 환경 ‘CentOS Linux release 7.9.2009 (Core)’에서 진행했다.

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 1	Oracle	Version 19.0.0.0.0- Production	‘OS_Umask’만 적용	‘OS_Umask’ 설정
CASE 2	PostgreSQL	PostgreSQL 13.1	‘OS_Umask’ ≥ ‘DB_Umask’
CASE 2	Tibero	6(DB 6.0 FS07_CS_2005)	‘OS_Umask’ ≥ ‘DB_Umask’
CASE 3	MySQL	8.0.22 MySQL Community Server - GPL	‘OS_Umask’ , ‘DB_Umask’ 각각 적용	‘OS_Umask’와‘DB_Umask’ 설정
CASE 3	MariaDB	10.5.8	‘OS_Umask’ , ‘DB_Umask’ 각각 적용	‘OS_Umask’와‘DB_Umask’ 설정
CASE 4	MongoDB	4.4.2	‘OS_Umask’ ≤ ‘DB_Umask’	‘DB_Umask’ 설정 후 ‘OS_Umask’ 설정
CASE 5	DB2	DB2 Client 11.5.4.0	-	UMASK 설정 불가

[표 13] UMASK 설정 우선 순위에 따라 분류한 데이터베이스

1) CASE 1 – Oracle

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 1	Oracle	Version 19.0.0.0.0- Production	‘OS_Umask’만 적용	‘OS_Umask’ 설정

[표 14] Oracle의 UMASK 설정 우선 순위

Oracle 데이터베이스는 ‘DB_Umask’ 설정이 존재하지 않는다. Oracle에서 ‘Export_File’과 ‘Data_File’의 UMASK 설정 방법과 변경 유무를 테스트를 통해 알아보고자 한다. ‘OS_Umask’의 설정이 ‘Data_File’과 ‘Export_File’의 권한에 어떤 영향을 주는지 확인하여 UMASK 설정 방법을 조사하고 기존 점검 방식이 올바른지 확인할 것이다.

(1) ‘OS_Umask’ 설정

‘OS_Umask’ 설정에 영향받는 대상을 알아보기 위해 OS에 접속한 계정과 해당 계정의 UMASK를 확인하고, ‘Data_File’과 ‘Export_File’을 생성한 후 각 파일의 적용된 권한을 확인한다.

순서	확인 방법 및 결과 이미지
①	접속한 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 15] Oracle ‘OS_Umask’ 설정의 영향받는 대상 확인 과정

‘OS_Umask’를 022로 설정한 테스트 결과에서 ‘Export_File’은 OS 접속 계정(oracle)의 ‘OS_Umask’가 적용되어 644 권한으로 생성되었다. 하지만 ‘Data_File’은 644가 아닌 640의 권한이 부여되었다. 해당 테스트로 정확한 결과를 알 수 없으므로 ‘OS_Umask’를 000으로 설정하여 추가 테스트를 진행했다. ‘OS_Umask’를 020로 설정했을 때, ‘Data_File’은 640 권한이 부여되었다. 추가 테스트를 통해 알아낸 결과는 ‘Data_File’의 UMASK는 기타 사용자의 권한은 항상 모두 제한되고, ‘OS_Umask’의 설정에서 소유자와 소유 그룹의 권한만 따른다는 사실이다.

(2) 테스트 결과

CASE 1의 테스트 결과 ‘OS_Umask’는 ‘Export_File’와 ‘Data_File’ 모두 영향을 주는 것으로 조사됐다. ‘Export_File’은 ‘OS_Umask’를 그대로 적용되고. ‘Data_File’의 권한은 ‘OS_Umask’에서 소유자와 소유 그룹의 권한만 상속받고 기타 사용자(Other)의 권한이 모두 제외된다. ‘DB_Umask’ 설정 방식은 존재하지 않으므로, Oracle은 UMASK 점검 시 기존 점검 기준으로 OS 접속 계정의 ‘OS_Umask’를 확인하면 된다.

구분	데이터베이스	UMASK 설정	UMASK 적용 대상	결론
CASE 1	Oracle	‘OS_Umask’	‘Export_File’	‘OS_Umask’가 모든 UMASK 설정
			‘Data_File’

[표 16] Oracle의 OS와 DBMS의 UMASK 상관관계

2) CASE 2 – PostgreSQL, Tibero

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 2	PostgreSQL	PostgreSQL 13.1	‘OS_Umask’ ≥ ‘DB_Umask’	‘OS_Umask’ 설정
CASE 2	Tibero	6(DB 6.0 FS07_CS_2005)	‘OS_Umask’ ≥ ‘DB_Umask’	‘OS_Umask’ 설정

[표 17] PostgreSQL과 Tibero의 UMASK 설정 우선 순위

PostgreSQL과 Tibero 데이터베이스는 ‘DB_Umask’ 설정이 아예 존재하지 않는 것은 아니다. ‘DB_Umask’는 변경할 수 없는 고정 값으로 설정되어 있기 때문에 ‘OS_Umask’가 ‘DB_Umask’ 설정보다 우선순위가 높거나 같다고 표기했다. 두 데이터베이스가 동일한 케이스이기 때문에 이번 테스트에서는 PostgreSQL만 진행할 예정이다. ‘OS_Umask’ 테스트를 통해 ‘DB_Umask’의 고정 값과 영향을 주는 대상도 함께 확인하려고 한다.

(1) ‘OS_Umask’ 설정

순서	확인 방법 및 결과 이미지
①	접속한 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 18] PostgreSQL ‘OS_Umask’ 설정의 영향받는 대상 확인 과정

테스트 결과 ‘OS_Umask’를 022로 설정하였을 때 ‘Export_File’은 OS 접속 계정(postgres)의 ‘OS_Umask’가 적용되어 644 권한으로 생성되었지만 ‘Data_File’에 영향을 주지 않을 것으로 보인다. PostgreSQL에서는 ‘Data_File’의 파일은 600, 디렉터리는 700으로 고정되어 있다. 파일 600, 디렉터리 700 권한은 변경할 수 없으며 항상 적용되는 기본 값이다.

(2) 테스트 결과

PostgreSQL은 ‘OS_Umask’ 설정이 ‘Export_File’의 UMASK 적용되어 변경할 수 있지만 ‘DB_Umask’는 항상 고정 설정으로 ‘Data_File’의 파일은 600, 디렉터리는 700으로 생성된다. PostgreSQL의 경우 ‘OS_Umask’는 수정 가능하고 ‘DB_Umask’ 수정 불가로, ‘OS_Umask’ 의 우선순위가 높다고 판단된다.

구분

데이터베이스

UMASK 설정

UMASK 적용 대상

결론

CASE 2

PostgreSQL,

Tibero

‘OS_Umask’

‘Export_File’

‘OS_Umask’의 UMASK 변경 가능,

‘DB_Umask’는 고정으로

UMASK 변경 불가

‘DB_Umask’

‘Data_File’

[표 19] PostgreSQL과 Tibero의 OS와 DBMS의 UMASK 상관관계

3) CASE 3 – MySQL, Maria

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 3	MySQL	8.0.22 MySQL Community Server - GPL	‘OS_Umask’ , ‘DB_Umask’ 각각 적용	‘OS_Umask’와‘DB_Umask’ 설정
CASE 3	MariaDB	10.5.8	‘OS_Umask’ , ‘DB_Umask’ 각각 적용	‘OS_Umask’와‘DB_Umask’ 설정

[표 20] MySQL, MariaDB의 UMASK 설정 방법

MySQL과 Maria 데이터베이스에서는 ‘OS_Umask’와 ‘DB_Umask’가 모두 설정 가능하다. 두 데이터 베이스가 동일한 우선순위와 설정 방법을 따르기 때문에 CASE 3에서는 MySQL에 대한 분석만 진행할 예정이다. 또한 설정 방법에 따라 영향받는 대상을 파악하기 위해서 ‘OS_Umask’와 ‘DB_Umask’ 설정을 각 4단계(① UMASK 확인, ② ‘Export_File’ 생성, ③ ‘Data_File’ 생성, ④ 생성된 파일들의 권한 확인)로 확인한 후, CASE 3에 대한 UMASK 상관관계를 도출하려 한다.

(1) ‘OS_Umask’ 설정

순서	확인 방법 및 결과 이미지
①	접속한 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 21] MySQL ‘OS_Umask’ 설정의 영향받는 대상 확인 과정

‘OS_Umask’ 설정 확인 결과 영향을 받은 건 ‘Export_File’이었다. ‘Export_File’은 tee 명령어로 쿼리의 결과물을 파일로 저장할 때 만들어진 파일이며, root의 UMASK 002가 적용되어 664 권한으로 생성되었다. 그리고 ‘Data_File’은 데이터베이스의 테이블을 생성하여 확인한 결과 ‘OS_Umask’ 설정을 적용받지 않은 700 권한으로 설정되었다.

(2) ‘DB_Umask’ 설정

‘DB_Umask’는 [표 22] ‘MySQL의 UMASK 설정 방법’을 따른다. (단, 이번 테스트에서는 UMASK 값을 4자리로 설정하는 8진수로 확인한다.) 해당 과정으로 UMASK를 설정한 후, 영향받는 대상을 조사하기 위해 ‘Data_File’과 ‘Export_File’을 생성하여 권한을 확인한다.

MySQL의 UMASK 설정 방법

• MySQL 서비스 파일(/usr/lib/systemd/system/mysqld.service)에서 [Service] 태그 하위의 UMASK 설정을 다음과 같이 수정한다.

• [Service] 태그 및 UMASK 설정이 존재하지 않을 경우, 해당 내용을 직접 추가해야 한다.

# vi /usr/lib/systemd/system/mysqld.service

[Service]

Environment=UMASK=[(10진수)420 이하 세 자리 수] 또는 [(8진수)0644 이하 네 자리 수]

Environment=UMASK_DIR=[(10진수)493 이하 세 자리 수] 또는 [(8진수)0755 이하 네 자리 수]

[표 22] MySQL의 UMASK 설정 방법

순서	설정
①	‘MySQL의 UMASK 설정 방법’에 따라 UMASK 값 설정
①
②	DB 접속 후 ‘Data_File’ 생성
②

[표 23] MySQL ‘DB_Umask’ 설정의 영향받는 대상 확인 과정(1,2)

순서	설정
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 24] MySQL ‘DB_Umask’ 설정의 영향받는 대상 확인 과정(3,4)

‘DB_Umask’ 설정에서 UMASK 값을 044로 설정한 결과 ‘Data_File’의 권한은 644, ‘Export_File’은 664로 생성되었다. 해당 테스트로 정확한 결과를 얻을 수 없어 DB_Umask’ 값을 066으로 적용한 추가 테스트를 진행했다. 추가 테스트 결과 ‘Data_File’의 권한은 666, ‘Export_File’은 664로 생성되었다. 따라서, ‘DB_Umask’은 ‘Data_File’에 영향을 주지만 소유자(owner)의 권한은 항상 6으로 고정되고 소유 그룹(group)과 비소유자(other)에만 UMASK가 적용되는 것을 확인할 수 있었다. 또한 파일의 기본 권한인 666에서 UMASK를 뺀 권한이 아닌 ‘DB_Umask’에 설정한 8진수 숫자로 이루어진 권한이 그대로 부여됐다.

(3) 테스트 결과

CASE 3의 테스트 결과 ‘OS_Umask’는 ‘Export_File’의 권한을 설정하고 ‘DB_Umask’는 ‘Data_File’에 영향을 주었다. 따라서, MySQL과 Maria는 OS와 DB의 UMASK 설정이 각각 적용되므로, 두 설정의 우선순위는 동일하다고 판단되며, 점검 시 두 설정 모두 확인해야만 한다.

구분

데이터베이스

UMASK 설정

UMASK 적용 대상

결론

CASE 3

MySQL,

MariaDB

‘OS_Umask’

‘Export_File’

‘OS_Umask’와 ‘DB_Umask’가

각 각 적용

‘DB_Umask’

‘Data_File’

[표 25] MySQL, MariaDB의 OS와 DBMS의 UMASK 상관관계

4) CASE 4 – MongoDB

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 4	MongoDB	4.4.2	‘OS_Umask’ ≤ ‘DB_Umask’	‘DB_Umask’ 설정 후 ‘OS_Umask’ 설정

[표 26] MongoDB의 UMASK 설정 방법

MongoDB는 ‘DB_Umask’ 설정을 갖고 있는 데이터베이스이다. 다른 데이터베이스와 다르게 특이한 점이 존재하는데 MongoDB의 ‘DB_Umask’ 설정에 따라서 영향받는 대상이 ‘DB_Umask’나 ‘OS_Umask’를 적용되기 때문이다. MongoDB 테스트는 OS 접속한 계정의 ‘OS_Umask’의 영향을 받는 대상을 확인하고, ‘DB_Umask’ 설정에 따른 ‘OS_Umask’의 연관성을 파악하고자 한다.

(1) ‘OS_Umask’ 설정

순서	확인 방법 및 결과 이미지
①	접속한 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 27] MongoDB ‘OS_Umask’ 설정의 영향받는 대상 확인 과정

‘OS_Umask’ 설정 확인 결과 영향을 받는 것은 ‘Export_File’이었다. OS에 접속한 계정의 UMASK를 000으로 설정할 경우 ‘Export_File’ 파일은 파일의 최대 권한인 666 권한이 부여됐다. 반면, ‘Data_File’은 ‘OS_Umask’의 영향을 받지 않았다.

(2) ‘DB_Umask’ 설정

‘DB_Umask’는 [표 28] ‘MongoDB의 UMASK 설정 방법’을 따른다. 해당 과정으로 UMASK를 설정한 후, 영향받는 대상을 조사하기 위해 ‘Data_File’과 ‘Export_File’을 생성하여 권한을 확인한다.

MongoDB UMASK 설정 방법

• [mongoDB config path]/mongod.conf 파일 내 honorSystemUmask와 processUmask를 설정한다.

• honorSystemUmask가 true일 경우 OS 접속 계정의 umask가 적용된다

• honorSystemUmask가 false일 경우 processUmask 값을 따르고, processUmask 값도 false일 경우 파일은 600, 디렉터리는 700으로 생성된다.

# vi [mongoDB config path]/mongod.conf

setParameter:

honorSystemUmask : [true/false]

processUmask : [umask 값/false]

[표 28] MongoDB의 UMASK 설정 방법

mongod.conf 파일의 setParameter: 하위 태그의 설정에 따라 서비스 구동 계정의 UMASK를 따르도록 하거나 고정 값으로 지정할 수 있다. mongod.conf 파일 내부 태그의 설정 값에 따라 결정되는 UMASK 값은 [표 29]와 같다. 이번 테스트에서는 honorSystemUmask은 true, processUmask는 설정 미존재로 주석처리 하여 MongoDB 구동 계정의 UMASK가 적용되는지 확인하고자 한다.

honorSystemUmask	processUmask	적용되는 UMASK
false	022	022
false/설정 없음	false/설정 미존재	파일 : 066/디렉토리 : 077
true	설정 미존재	서비스 구동 계정의 UMASK
true	022	(서비스 구동 불가)

[표 29] mongod.conf 파일의 UMASK 설정

순서	확인 방법 및 결과 이미지
①	MongoDB 구동 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 30] MongoDB ‘DB_Umask’ 설정의 영향받는 대상 확인 과정

‘DB_Umask’ 설정 테스트 결과 MongoDB 프로세스를 구동하고 있는 계정은 root로 확인되었고 root 계정의 umask 002로 설정된 상태이다. 데이터베이스에 접속하여 ‘Data_File’과 ‘Export_File’을 생성하고 각 각의 권한을 확인한 결과 모든 파일의 권한이 664로 부여됐다. ‘DB_Umask’의 설정을 데이터베이스를 구동하는 계정의 ‘OS_Umask’를 따르게 설정했기 때문이다. 하지만 여기서 ‘Export_File’이 ‘DB_Umask’의 설정이 적용되었다고 보긴 어렵다. OS에 접속한 계정과 DB를 구동한 계정이 root로 일치하여 ‘Export_File’이 ‘DB_Umask’에 영향을 받은 것처럼 보이는 것이다. 만약 DB를 구동한 계정과 OS에 접속한 계정이 일치하지 않을 경우 ‘Export_File’은 OS에 접속한 계정의 UMASK를, ‘Data_File’은 DB를 구동한 계정의 UMASK를 따르게 된다.

(3) 테스트 결과

CASE 4의 테스트 결과 ‘DB_Umask’는 ‘Data_File’의 UMASK를 설정할 수 있고 ‘OS_Umask’는 ‘Export_File’과 ‘Data_File’의 UMASK를 설정한다. 여기서 DBMS의 자체 설정에 따라 ‘OS_Umask’의 영향이 두 대상 모두에 적용되거나 ‘Export_File’ 한 대상에만 적용될지 결정되므로, ‘DB_Umask’가 ‘OS_Umask’ 설정보다 우선순위가 높다고 판단된다.

구분

데이터베이스

UMASK 설정

UMASK 적용 대상

결론

CASE 4

MongoDB

‘OS_Umask’

‘Export_File’

‘Data_File’

‘DB_Umask’의 설정에 따라 ‘OS_Umask’의 영향도가 결정

‘DB_Umask’

‘Data_File’

[표 31] MongoDB의 OS와 DBMS의 UMASK 상관관계

5) CASE 5 – DB2

구분	데이터베이스	버전	UMASK 적용 우선 순위	UMASK 설정 방법
CASE 5	DB2	DB2 Client 11.5.4.0	-	UMASK 설정 불가

[표 32] MongoDB의 UMASK 설정 방법

DB2는 데이터베이스 자체 UMASK 설정 방법이 존재하지 않는다. 또한 ‘OS_Umask’의 설정도 적용되지 않는다고 알려져 있기 때문에 ‘OS_Umask’ 설정을 변경하여 산출되는 파일들의 권한을 확인하여 ‘Export_File’과 ‘Data_File’의 UMASK의 변경 가능 유무를 알아보려 한다.

(1) ‘OS_Umask’ 설정

순서	확인 방법 및 결과 이미지
①	접속한 계정의 UMASK 값 확인
①
②	DB 접속 후 ‘Data_File’ 생성
②
③	DB 접속 후 ‘Export_File’ 생성
③
④	생성된 ‘Data_File’과 ‘Export_File’ 권한 확인
④

[표 33] MongoDB ‘OS_Umask’ 설정의 영향받는 대상 확인 과정

‘OS_Umask’를 222로 설정한 뒤 ‘Data_File’과 ‘Export_File’을 생성했을 때, ‘Data_File’은 600, ‘Export_File’은 664로 두 대상 모두에게 영향을 주지 않았다. 정확한 테스트 결과를 도출하기 위해 ‘OS_Umask’를 000로 설정하여 재확인한 결과도 동일했다.

(2) 테스트 결과

CASE 5 DB2는 UMASK 설정이 아예 불가능한 것으로 확인됐다. DBMS의 자체 설정은 존재하지 않았고 ‘OS_Umask’ 또한 ‘Export_File’과 ‘Data_File’에 적용되지 않았으므로, 두 설정간의 상관관계를 확인할 수 없다. 하지만 DB2 공식 문서에 따르면 보안 위협의 예방을 위해서 DB2 설치 시 사용된 계정과 운영 계정의 UMASK를 관리해야 된다고 명시되어있다.

구분	데이터베이스	UMASK 설정	UMASK 적용 대상	결론
CASE 5	DB2	‘OS_Umask’	-	UMASK 변경 불가
CASE 5	DB2	‘DB_Umask’	-	UMASK 변경 불가

[표 34] DB2의 OS와 DBMS의 UMASK 상관관계

04. 결론

1) OS UMASK와 DB UMASK 상관관계 분석 결과

OS UMASK와 DBMS UMASK의 상관관계를 분석한 결과는 [표 35]와 같다. 자체적인 UMASK 설정 기능을 갖고 있는 MySQL, MariaDB, MongoDB의 경우 DBMS에 설정된 UMASK가 데이터베이스의 내부 데이터파일에 영향을 주고 있었다. 또한 MongoDB 같은 경우는 DBMS의 설정에 따라 OS UMASK를 확인하는 대상이 변경되므로 DBMS UMASK 설정이 매우 중요하다고 판단된다. Oracle, PostgreSQL, Tibero의 UMASK에 영향을 주는 설정은 OS UMASK였고, DB2는 UMASK 변경이 불가능한 것으로 확인되었다.

구분	DBMS	UMASK 상관관계	점검 방법
CASE 1	Oracle	‘OS_Umask’가 모든 UMASK 설정	• OS 접속 계정의 UMASK 확인
CASE 2	PostgreSQL	‘OS_Umask’의 UMASK 변경 가능, ‘DB_Umask’는 고정으로 UMASK 변경 불가	• OS 접속 계정의 UMASK 확인
CASE 2	Tibero	‘OS_Umask’의 UMASK 변경 가능, ‘DB_Umask’는 고정으로 UMASK 변경 불가	• OS 접속 계정의 UMASK 확인
CASE 3	MySQL	‘OS_Umask’와 ‘DB_Umask’가 각 각 적용	• OS 접속 계정의 UMASK 확인 • DBMS 설정 파일 내부 UMASK 확인
CASE 3	MariaDB	‘OS_Umask’와 ‘DB_Umask’가 각 각 적용	• OS 접속 계정의 UMASK 확인 • DBMS 설정 파일 내부 UMASK 확인
CASE 4	MongoDB	‘DB_Umask’의 설정에 따라 ‘OS_Umask’의 영향도가 결정	• OS 접속 계정의 UMASK 확인 • DBMS 설정 파일 내부 UMASK 확인 • DBMS 설정 파일에 ‘서비스 구동 계정의 UMASK 적용’으로 설정될 경우, MongoDB 구동 계정의 UMASK 확인
CASE 5	DB2	UMASK 변경 불가	• OS 접속 계정의 UMASK 확인

[표 35] OS UMASK와 DBMS UMASK 상관관계 분석 결과

따라서, 분석한 7개의 데이터베이스의 UMASK를 점검하기 위해서는 데이터베이스를 구동하기 위해 OS에 접속한 계정의 UMASK를 확인해야 하며, DBMS 자체 UMASK 설정 기능이 존재할 경우 해당 설정 파일의 설정 값을 반드시 확인해야 한다.

2) Output File의 UMASK 변경 가능 여부

UMASK 상관관계 분석을 통해 Output File의 UMASK 변경 가능 유무로 DBMS를 분류할 수 있었다. Output File 이란 분석에 사용된 용어 중 ‘Data_File’과 ‘Export_File’을 의미한다. 7개의 데이터베이스 중에서 Oracle, MySQL, MariaDB, MongoDB가 ‘Data_File’와 ‘Export_File’의 UMASK 변경이 가능하다. PostgreSQL, Tibero는 ‘Export_File’의 UMASK만 변경할 수 있었고, DB2는 UMASK 변경이 불가능하다.

[그림 6] Output File의 UMASK 변경 유무로 분류한 DBMS

‘Data_File’의 UMASK 변경이 가능한 것의 의미는 데이터베이스 내부에서 생성되는 테이블, 테이블스페이스 등 데이터베이스 정보가 저장된 파일과 디렉터리의 권한이 취약하게 설정될 위험이 존재한다는 것이다. ‘Data_File’의 UMASK가 취약하게 적용되어 비인가자의 접근이 허용될 경우 중요 정보를 탈취 및 변조될 위험이 존재한다.

최근 ‘데이터 3법’의 개정으로 개인과 기업 모두에게 데이터의 사용도, 활용도의 폭이 넓어졌다. 가명 정보를 정보 주체의 동의를 구하지 않고 활용할 수 있으며, 상업적인 목적으로도 사용할 수 있으며, 여러 기업에서 수집한 데이터가 결합되고 공유되면서 데이터의 규모는 무궁무진하게 커질 것이다. 개인 정보의 활용도가 증가된 만큼 개인 정보보호의 중요성도 높아질 수밖에 없는데, 예를 들면 가명의 데이터라도 카드 사용처와 통신사 내역 등 각종 민감한 정보가 유출되어 서로 결합되면 정보의 주체를 파악할 수 있기 때문이다. 개인 정보의 유출 및 도용 위협을 예방하기 위해서는 데이터베이스의 내부 데이터에 대해서도 보안 관리가 필수적이다.

또한 ‘Data_File’이 변경 가능한 DBMS 중에서 Oracle과 MySQL, MongoDB는 [그림 7] ‘DB-Engines Ranking’ 기준의 데이터베이스 선호도 수치를 보더라도 1, 2, 5위로 높은 비율을 차지하는 것을 알 수 있다. 해당 DBMS는 실제로 기업에서 많이 사용되는 서비스임에도 불구하고 ‘Data_File’의 안전한 UMASK 설정을 명시하는 가이드라인이 미비하기 때문에 금번 분석 결과를 통해 안전한 설정에 대한 고려가 필요하다.

[그림 7] DB-Engines Ranking - Trend Popularity, April 2021

데이터베이스의 중요도가 높아짐에 따라 데이터베이스 내부에서 생성되는 데이터파일에 비인가자의 접근을 제한해야 하며, UMASK는 최소한의 권한만 부여할 수 있도록 설정 및 관리가 필요하다.

05. 대응방안

1) 계정 관리

DBMS의 보안 관리를 위해서 가장 기본이 되는 부분은 계정 관리이다. DBMS 설치 시 UMASK를 최소한의 권한으로 설정한 뒤 설치를 진행하고, DBMS를 운영할 때는 서비스 전용 계정으로 DBMS를 구동하고, 서비스 전용 계정의 UMASK도 설정 및 관리해야 한다.

구분

설명

DBMS 설치 시

설치 시 OS에 접속한 계정의 UMASK를 022로 설정

DBMS 운영 시

관리자 계정이 아닌 서비스 전용 계정으로 DBMS를 운영하며

해당 계정의 UMASK를 022로 설정

[표 36] DBMS 계정 관리 방법

2) 로그 및 감사 기능 설정

로그와 감사 기능이 설정되지 않을 경우 외부의 침입 등 문제가 발생했을 경우 공격 행위에 대한 식별이 어려울 수 있으며 원인을 파악하기 어렵다. 문제 발생 시 원활한 대응을 위해서라도 로그 및 감사 기록을 수립하여 정기적으로 관리해야 한다.

구분	설명
OS 로그의 정기적 검토 및 보고	정기적인 로그 분석을 위하여 아래와 같은 절차 수립
OS 로그의 정기적 검토 및 보고	① 정기적인 로그 검토 및 분석 주기 수립 ② 로그 분석에 대한 결과 보고서 작성 ③ 로그 분석 결과보고서 보고 체계 수립
DBMS 자체 감사 기능 실행	데이터베이스 감사 기록 정책 및 백업 정책 수립
DBMS 자체 감사 기능 실행	Oracle 예시) AUDIT 기능을 활성화하고 데이터베이스 감사 기록 정책 및 백업 정책을 수립한다. ① SQL> ALTER SYSTEM SET AUDIT_TRAIL=[AUDIT_TRAIL 값] SCOPE=SPFILE; ② SQL> STARTUP FORCE;

[표 37] OS와 DBMS 감사 기능 설정 방법

3) 원격 접속 제한(허가되지 않은 IP와 Port 접속 제한)

OS와 DBMS에 접근 통제 관리가 이뤄지지 않을 경우 악의적인 사용자가 내/외부에서 접근할 수 있는 위험이 존재한다. 접근 제어 정책을 설계 및 적용하여 지정된 IP와 포트를 통해서만 접근 가능하도록 제한해야 한다.

구분	설명
OS 접속 제한	TCP Wrapper 접근 제어를 사용
	• /etc/hosts.deny : 시스템 접근을 제한할 IP 설정 • /etc/hosts.allow : 시스템 접근을 허용할 IP 설정 • hosts.deny와 hosts.allow 어느 곳에도 없는 경우 : 모든 접근 허용
	iptables 사용
	• iptables 명령어를 통해 접속할 IP 및 포트 정책 추가 예시) #iptables –A INPUT –p tcp –s 192.168.1.24 --dport 22 –j ACCEPT
DBMS 접속 제한	DB서버에 지정된 IP 주소만 접근 가능하도록 제한
DBMS 접속 제한	Oracle 예시) ① spfile을 사용하는 경우 아래 명령어 실행 SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENT=FALSE SCOPE=spfile; ② pfile을 사용하는 경우 init.ora 파일에 설정 SQL> ALTER SYSTEM SET REMOTE_OS_AUTHENT=FALSE;

[표 38] OS와 DBMS 접속 제한 방법

06. 참고자료

[1] UMASK 기술 설명

https://pubs.opengroup.org/onlinepubs/007908799/xcu/umask.html

[2] Bash Shell 개념

https://wiki.archlinux.org/index.php/Bash

[3] Shell Mode 개념

https://blog.opstree.com/2020/02/11/shell-initialization-files/

[4] Oracle UMASK 설정

https://docs.oracle.com/cd/E56343_01/html/E53950/secfile-62.html

[5] MySQL UMASK 설정

https://dev.mysql.com/doc/refman/8.0/en/file-permissions.html

[6] PostgreSQL 서버 설정

https://www.postgresql.org/docs/12/runtime-config-connection.html

[7] Tibero 안내서

https://technet.tmaxsoft.com/download.do?filePath=/nas/technet/technet/upload/kss/tdoc

/tibero/2015/02/&fileName=FILE-20150227-000001_150227144852_1.pdf

[8] DB2 UMASK 설정

https://www.ibm.com/support/pages/supported-user-mask-umask-configuration-db2-

ervers

[9] MongoDB UMASK 설정

https://docs.mongodb.com/manual/reference/parameters/#param.honorSystemUmask

[10] MariaDB UMASK 설정

https://mariadb.com/kb/en/systemd/#configuring-the-umask

[11] 2021 주요정보통신기반시설 기술적 취약점 분석ㆍ평가 방법 상세가이드

https://www.krcert.or.kr/data/guideView.do?bulletin_writing_sequence=35988&queryStrin

g=YnVsbGV0aW5fd3JpdGluZ19zZXF1ZW5jZT0zNTk4OA==

Quick Link

보안정보