이메일 보안 3, 데이터베이스 보안 1,2,3

** 이메일 인증 기술 (스팸 방지 기술)
1) SPF (Sender Policy Framework) 기술
- 수신한 메일의 발신자 메일주소가 정당한 서버에서 온 것인지 검증하는 기술 (=발송자 메일서버 인증, 메일서버 등록제)

- 발신자 메일주소를 조작하더라도, 인증된 메일서버 IP가 아니므로 수신측은 신뢰하지 않음

동작
1. 발신 도메인 DNS서버에 발신 메일서버 정보를 담고 있는 SPF 레코드(인증된 메일서버 IP, 메일 처리 기준 포함)를 도메인의 TXT 레코드에 등록
2. 발신자가 메일 전송
3. 발신 도메인에 대한 SPF 레코드 조회 (TXT 레코드 질의)
4. 조회한 SPF 레코드 정책에 따라 수신 여부가 결정됨

 

test.co.kr   600   IN   TXT   "v=spf1   ip4:192.168.11.1   ip4:211.11.22.0/24  ... include: SPFtest.co.kr  -all"
=> dig로 TXT 명령 결과 예시. include는 이 도메인의 SPF 레코드를 참고하라는 뜻 -all은 그 외의 모든 것은 실패처리하라는 뜻

 

 

SPF 레코드 형식
가) 버전과 하나 이상의 한정자와 메커니즘의 조합으로 이루어진 텍스트

구분	값	설명
버전 Version	v=spf1	레코드 버전
한정자 Qualifier	+ - ~ ?	메커니즘과 함께 사용됨. 어떻게 처리할지 알려주는 역할
메커니즘 Mechanism	ip4 ip6 include all 등	ip4/ip6 : ipv4, ipv6 include : 지정한 도메인의 spf 레코드 정보 참조 all : 모든 주소

 

나) 한정자의 종류

1. + : 인증 통과 (생략가능)

2. - : 인증 실패 또는 심각한 인증 실패 (거부, 차단)

3. ~ : 가벼운 인증 실패 (메일서버 정책에 따라 판단하라는 뜻)

4. ? : 중립

 

다) 예시

v=spf1   ip4:192.168.11.1   ip4:211.11.22.0/24  -all

=> ipv4 주소가 192.168.11.1이거나 211.11.22.0/24이면 통과. 그 외의 주소는 거부(fail, hard fail)하라는 뜻

 

v=spf1   include: SPFtest.co.kr  ~all

=> 해당 도메인의 SPF레코드 정책 참고. 그 외에는 수신측 메일서버 정책에 따라 판단 (Soft fail)

 

 

 

2) DKIM 인증 기술

- 발신 메일서버에서 메일 메세지에 대한 디지털 서명을 추가해, 메일의 위변조 여부를 검증할 수 있는 기술 (= 도메인 키 인증메일)

 

동작방식
1. 디지털서명 검증정보를 담은 DKIM 레코드(서명 알고리즘, 공개키)를 발신 DNS서버의 TXT 레코드에 등록
2. 개인키로 서명 후 DKIM-Signature 헤더(서명값+도메인정보) 추가하여 메일 발송
3. 헤더에 기재된 도메인에 대한 TXT(DKIM 포함) 레코드 조회
4. 디지털 서명 검증 수행

 

DKIM 레코드 예시
20210222_domainkey.naver.com   300   IN   TXT   "v=DK1M1; k=rsa; p=어쩌구저쩌구공개키정보base54인코딩됨"

 

DKIM 헤더 예시

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=naver.com; s=20240222     h=mine-version;어쩌구저쩌구...     bh=메시지 바디 데이터를 서명한 서명값     b=h 태그에 명시한 헤더 데이터의 서명한 서명값

 

헤더 태그

v	버전
a	디지털 서명 알고리즘 ex rsa-sha256 : sha256으로 해시한 후 rsa 알고리즘으로 디지털서명
h	서명 대상 메시지 헤더 리스트

 

 

 

3) DMARC(Domain-based Message Authentication, Reporting and Conformance) 기술

- SPF 인증기술과 DKIM 인증기술을 모두 사용하고, 모니터링까지 가능한 인증 기술

동작방식
1. 인증에 사용할 SPF, DKIM 및 DMARC 레코드를 도메인의 TXT 레코드에 등록
2. 개인키로 서명 후 메일에 DKIM-Signature 헤더 추가하여 전송
3. 헤더에 지정된 도메인의 TXT 레코드 안의 DMARC, SPF, DKIM 조회
4. DMARC 정책에 따라 SPF, DKIM 인증 수행 및 인증 실패시 처리(실패 보고서 피드백)

 

dig _dmarc.naver.com TXT 명령 실행 예시
_dmarc.naver.com   600   IN   TXT   "v=DMARC1; p=none;  sp=quarantine;  rua=mailto:mailauth-reports@naver.com"

 

rua: 실패 보고서 피드백을 받을 메일주소

 

주요 메일 헤더 정보

Received: from r145 k1.email.samsung.com (r145 k1.email.samsung.com [192.168.11.112])    by mx.naver.com with ESMTPS id 38uniqueiddata 2023.01.11    for <test@naver.com>    (version=TLS1.2 cipher=ECDHE-AES128-GCM-SHA256 bits=128/128)     하략 Received-SPF: pass (naver.com: domain of bounce@어쩌구 저쩌구...) Authentication-Results: mx.naver.com;    dkim=pass ... 중략    spf=pass ... 중략    dmarc=pass ... 중략 DKIM-Signature: v=1; a=rsa-sha256;    c=relaxed/relaxed; 중략    bh=... 중략    h=... 중략    b=... 중략 Date: Fri, 11, Jan 2023 10:11:12 하략 Form: "테스트" <test@k1.email.samsung.com> To: test@naver.com

1. Received : 실제 메일이 전송된 경로. Received 헤더가 여러 개인 경우는 여러 메일 서버를 경유했다는 의미.
가장 아래에 보이는 헤더가 처음 메일을 발송한 메일서버를 의미함.
스팸 메일 분석 시 발송 근원지를 역추적하기 위해 참고

(Received : from 발송호스트 by 수신호스트 id 메일 고유 식별자 for 수신자 메일주소 수신날짜시간)

 

2. SSL/TLS를 지원하는 SMTPS를 적용한 경우

TLS Cipher Suite	프로토콜_키교환알고리즘_인증/서명알고리즘_WHTH_대칭키블록암호알고리즘_블록암호운용모드_메시지인증알고리즘 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Received Cipher Suite	키교환알고리즘_인증/서명알고리즘_대칭키블록암호알고리즘_블록암호운용모드_메시지인증알고리즘 ECDHE_RSA_AES_128_GCM_SHA256

ECDHE : 타원곡선임시디피헬만. TLS 통신 키교환을 위해 사용
RSA : 인증서명 알고리즘
AES128 : 대칭키 블록암호 알고리즘
GCM : 운영모드
SHA256 : 메시지 인증 알고리즘 HMAC

 

3. Received-SPF

- 수신자 메일서버에서 SPF 인증 결과를 기록한 헤더. ( Authentication-Results 에서도 확인 가능 )

 

4. Authentication-Results

- SPF, DKIM 및 DMARC 인증 결과를 기록하는 헤더

 

실제 네이버 메일에서 확인 가능한 헤더 참고 ARC-Seal: i=1; a=rsa-sha256; d=naver.com; s=arc-20180730; t=1711985331; cv=none; b=Mdzj3D8k4Pg1N04bGOtmQsZql3uZY9M40IEBog1 ... 하략 ARC-Message-Signature: i=1; a=rsa-sha256; d=naver.com; s=arc-20180730; t=1711985331; c=relaxed/relaxed; bh=T11inC9quclwTurcLbA중략Y=; h=dkim-signature:from:date:message-id:subject:to; b=B/IK4VrzZoZBw29JIFm  eOXzPJ1wyzRYtx... 하략 ARC-Authentication-Results: i=1; mx.naver.com;    spf=pass (mx.naver.com: 어쩌구 저쩌구 ) smtp.mailfrom=cor.fing@gmail.com;   dkim=pass header.i=@gmail.com;   dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: <cor.fing@gmail.com> Received-SPF: pass (mx.naver.com: 어쩌구 저쩌구 )   client-ip=209.85.160.54; x-iptype=white; Authentication-Results: mx.naver.com;   spf=pass (mx.naver.com: 어쩌구 저쩌구 ) smtp.mailfrom=cor.fing@gmail.com;   dkim=pass header.i=@gmail.com;   dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com X-Naver-ESV: +rFYpB3G1H+qbrJmjAKwjAu9Ko29KBwBjg== X-Session-IP: 209.85.160.54 Received: from mail-oa1-f54.google.com  하략 Received: by mail-oa1-f54.google.com with SMTP id 586e중략...         for <h940610@naver.com>; Mon, 01 Apr 2024 08:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;         d=gmail.com; s=20230601; t=1711985328; x=1712590128; darn=naver.com;         h=to:subject:message-id:date:from:mime-version:from:to:cc:subject          :date:message-id:reply-to;         bh=T1중략8/0MG3UY=;         b=U8WnldY3+R0ZeZQiBlDQW... 하략 ... 중략 To: ㅇㅇㅇ@naver.com Content-Type: multipart/alternative; boundary="000000000000572c6d... 하략"

 

정리
이메일 인증을 위한 기술적 대응방안
- 발신자 메일을 사칭하는 스팸메일에 대응하기 위해서는, SPF 인증기술을 통해 인증된 발신자 메일서버로부터 온 메일인지 확인하고
DKIM 인증기술을 통해 메일의 헤더나 내용이 위변조되지 않았는지 확인하는 한 편,
DMARC 인증기술로 정책에 따른 SPF와 DKIM의 이중적용 및 수신이 실패되는 메일에 대한 모니터링 등이 필요하다

 

 

이메일 보안 3 END --

 

 

데이터베이스 보안 위협과 통제

1) 데이터베이스 보안 위협
가) 집성 Aggregation
- 낮은 보안 등급의 정보 조각들을 조합하여, 높은 보안 등급의 정보를 알아내는 것
- 개별 데이터 항목보다 종합 정보의 보안 등급이 높은 경우, 기밀 정보 유출의 문제가 발생

나) 추론 Inference
- 일반 사용자가 보안으로 분류되지 않은 정보를 정당하게 접근하여 기밀 정보를 유추해내는 행위
- 주로 통계 정보로부터 발생하므로, 통계 정보로부터 개개의 개체에 대한 정보를 추적하지 못하도록 해야 한다

2) 데이터베이스 보안 통제(제어) (세 가지 통제 용어를 알아두고, 구분할 수 있도록 함)
가) 접근 통제(제어)
1. 데이터베이스 사용자가 가진 접근 권한의 범위 내에서 데이터 접근을 허용하는 기술적인 방법
2. 데이터베이스 관리자는 접근 통제를 위해 개별 사용자 또는 역할/그룹별로 다음과 같은 사항을 결정
 - 접근 가능한 데이터
 - 데이터 접근 수준
 - 데이터에 허용할 작업 (C생성 R읽기 U갱신 D삭지)

 

나) 추론 통제

1. 통계 정보 등 간접적으로 노출된 데이터를 통해 민감/기밀 데이터가 유추되는 것을 방지하는 것
2. 일반적인 추론 방지를 위한 방법
 - 허용 가능한 질의 제한
 - 질의의 응답으로 제공되는 데이터를 한정
 - 데이터가 숫자이면 반올림하거나 일관성 없는 질의 결과 제공

 

다) 흐름 통제

1. 접근 가능한 객체들 간의 정보의 흐름을 조정
2. 보안 등급이 높은 객체에서 낮은 객체로의 흐름을 제어해야 한다 (보안 등급이 높은 객체의 기록이, 낮은 객체에 기록되지 않도록)

 

 

 

DBMS 보안 통제
1) SQL 문 분류
가) DML(Data Manipulation Language) 데이터 조작어
- 데이터를 조작하는데 사용하는 sql문
- select, update, insert, delete

나) DDL(Data Definition Language) 데이터 정의어
- 데이터베이스 객체를 정의하거나 삭제 또는 변경하는 데 사용하는 sql문
- create, drop, alter

다) DCL(Data Control Language) 데이터 제어어
- 데이터베이스 관리목적으로 데이터베이스 객체에 대한 권한을 부여하거나 제거할 때 사용하는 sql문
- grand, revoke

라) TCL(Transation Control Language) 트랜잭션 제어어
- 논리적인 작업의 단위를 묶어, DML에 처리된 결과를 작업단위로 제어하는 명령어
- commit, rollback

 

 

2) 뷰View 기반의 접근 통제
개요
1. 뷰View : 하나 이상의 기본 테이블로부터 유도되어 만들어지는 가상의 테이블. 뷰는 실행시간에 구체화된다.

2. 뷰는 그 정의 자체를 권한부여 기법으로 사용할 수 있다. 기본 테이블에 대한 직접 접근을 차단하고, 기본 테이블에서 허용하는 일부 컬럼에 대해서만 뷰를 통해 제공하여 민감한 데이터를 은닉할 수 있다.

 

예시

create view m_view as select id, name from member;
=> member 테이블의 id와 name 필드만 사용해서 view를 생성
그 이후, 불필요한 그룹, 사용자의 member 테이블에 대한 접근권한을 제거하고 m_view에 대한 접근권한만 부여한다.

 

 

3) SQL 기반의 접근 통제 (grant/revoke)
개요
- 뷰는 데이터베이스 객체에 수행하는 작업(DML/DDL)에 대해 제한할 수 없다
- DCL문 (GRANT/REVOKE)을 이용하면 데이터베이스 객체에 대한 작업 권한을 제한할 수 있다

권한부여 예시
형식) GRANT "부여할 권한" ON "객체명" TO "사용자" [WITH GRANT OPTION]
    ex GRANT CREATE ON TESTDB.MEMBER TO USER1@LOCALHOST  WITH GRANT OPTION;

        (grant create on testdb.member to user1@localhost with grant option;)

 

[WITH GRANT OPTION] : 사용자가 부여받은 권한을 다른 사용자에게 또 다시 부여할 수 있는 권한

 

CREATE, ALTER, DROP : 데이터베이스 객체 생성/변경/삭제
SELECT, INSERT, UPDATE, DELETE 테이블의 레코드 조회/입력/수정/삭제
ALL : 모든 권한
USAGE : 권한 없음

 

MYSQL 기준 권한 확인
: show grants for user1@localhost

 

 

3) REVOKE 문을 이용한 권한 해제

형식) REVOKE "해제할 권한" ON "데이터베이스 객체" FROM "사용자"

     ex revoke select on testdb.member from user1@localhost;

 

 

데이터베이스 보안 1 END --

 

 

데이터베이스 암호화 기술
1) 개요
- 컬럼 암호화 방식 : 컬럼 단위로 데이터를 암호화하여 저장 (API 방식, Plug-In 방식, Hybrid 방식)
- 블록 암호화 방식 : DBMS 블록 또는 파일 블록 단위로 암호화하여 저장 (TDE 방식, 파일 암호화 방식)

2) 컬럼 암호화 방식
1. API 방식 : 응용 프로그램 자체 암호화
- 암복호화 모듈이 API 라이브러리 방식으로 각 어플리케이션 서버에 설치되어, 응용 프로그램에서 암복호화 모듈을 호출하는 방식.
- 어플리케이션 서버와 DB 서버간의 통신에서 암호화된 데이터 전송을 보장
- db 서버에 영향을 주지 않아 db서버 성능 저하가 적은 편이지만, 구축 시 응용 프로그램 전체 또는 일부의 수정이 필요

2. Plug-In 방식 : db 서버 암호화 방식

- 암복호화 모듈이 DB 서버에 설치되고, DB서버에서 플러그인으로 연결된 암복호화 모듈을 호출하는 방식
- 응용프로그램의 수정은 최소화되나 기존 DB 스키마와 대응하는 뷰를 생성하고 암호화할 테이블을 추가하는 등의 작업 필요
- 기존 테이블 이름과 동일한 뷰와, 변경된 이름의 암호화 테이블이 생성되고 암호화 전 원본 테이블은 삭제
- 뷰는 암호화된 테이블에 저장된 데이터를 복호화해서 보여주는 통로 역할을 수행한다.
- DML 요청이 발생하면, 트리거Trigger를 통해 암호화하여 암호화된 테이블에서 처리
- db 서버에서 추가적인 부하가 발생하여 성능이 저하될 수 있다. 민감성이 낮은 시스템에 적용하기 적합

3. Hybrid 방식 : API 방식과 Plug-In 방식 혼용

- 대용량 트랜잭션 처리와 같이 Plug-In 방식을 사용할 경우 성능저하가 발생할 수 있는 부분은 API 방식을 사용하여 최적의 성능을 보장
- 나머지 부분은 Plug-In 방식을 사용

 

컬럼 암호화 방식 특징 및 장단점 비교

API	어플리케이션 소스 수정 (암복호화 모듈 api 적용)	암복호화 속도 빠름 (대용량 트랜잭션에 적합) DMBS 부하가 적음 암호화 구간이 길다	어플리케이션 변경에 따른 개발 비용 발생 적용된 어플리케이션 패치에 영향받음
Plug-In	DBMS내 Plug-In 형식 암복호화 모듈 적용 (외부 모듈임)	어플리케이션 변경 최소화	대용량 처리시 DB서버 부하가 큼 DBMS 패치에 영향받음 암호화 구간 짧음

 

 

3) 블록 암호화 방식

1. TDE (Transparent Data Encryption) 방식

- DBMS에 내장된 암호화 기능을 이용해 DB 내부에 파일 저장시 암호화하고, 파일에 저장된 내용을 메모리 영역으로 가져올 때 DBMS에 의해 자동으로 복호화 되는 방식
- DBMS 커널 수준에서 처리되므로 수정/변경이 거의 필요하지 않고 엔진에 최적화된 성능 제공
- DBMS 종류 및 버전에 따라 기능 지원 여부가 결정됨

(Plug-In은 외부 모듈이고, TDE는 내부 모듈을 사용한다)

 

2. 파일 암호화 방식 : 운영체제 암호화 방식
- 운영체제에서 파일을 암호화하는 방식. DB 파일뿐 아니라 다양한 비정형 데이터 암호화 적용 가능.
- 수정할 부분이 크지 않고 거의 모든 DBMS에 적용 가능한 장점이 있으나, 파일 전체를 암호화하는데 따른 DB 서버 부하가 발생할 수 있고, 운영체제에 따라 지원 여부가 달라진다

 

 

 

데이터베이스 보안 2 END --

 

 

 

데이터베이스 취약점 점검
개요
1. MYSQL은 오라클에서 관리, 배포하고 있는 오픈소스 관계형 데이터베이스 관리시스템이다.
2. mysql 이라는 데이터베이스가 최초 생성된다.
 주요 기본 테이블
 - user : 전체 데이터베이스에 적용되는 사용자 정보와 권한정보
 - host : 호스트 전체에 대한 접근권한 정보
 - db : 각각의 데이터베이스에 대한 접근권한 정보
 - table_priv : 테이블에 대한 접근권한 정보
 - columns_priv : 테이블의 컬럼에 대한 접근권한 정보

DBMS 취약점 점검
1) 디폴트 관리자root 패스워드 및 계정명 변경

가) 디폴트 설치 시 root 계정은 패스워드가 비어있다. (시스템의 루트말고 mysql의 root 계정)

 

mysql -u root -p

첫 접속 시도시, 패스워드가 비어있으므로 인증없이 접속가능

 

패스워드 설정 : update user set password=password('password value') where user='root';

                          flush privileges;             <- 저장명령어

 

나) root를 Brute Force/Dictinary 공격에 대비해 계정명 변경
update user set user='adUser9984' where user='root';
flush privileges;

 

(원격에서 접속시 mysql -h 옵션을 사용해서 접속할 수 있다)

(host 테이블의 %는 root를 제외한 모든 호스트를 의미함)

 

 

2) mysql 설치시 자동으로 생성되는 시스템(서버)의 mysql 계정의 로그인을 차단

- /etc/passwd 파일을 점검하여 mysql의 마지막 필드, 로그인 쉘을 /bin/flase 또는 /sbin/nologin 으로 변경한다

 

3) 원격에서 mysql 접속을 차단한다

- mysql의 디폴트 서비스 포트인 3306 tcp 포트를 차단하여, 로컬에 설치된 어플리케이션에 의해서만 접근 가능하게 한다

- my.cnf 파일의 [mysqld]의 skip-networking 설정을 하면 네트워킹 기능을 비활성화한다.

(로컬에서는 mysql.sock 유닉스 도메인 소켓을 이용해 통신할 수 있다)

유닉스 도메인 소켓 IPC (Inter-Process Communication)

 

( 짤막복습
netstat -antp | grep mysql
mysql 포트 열려있는지 확인하기 )

 

4) 데이터베이스의 사용자별 접속/권한 설정 확인

1) user 테이블의 host 컬럼은 해당 사용자가 데이터베이스에 접근할 수 있는 호스트를 지정하는 컬럼이다.
 - localhost : 로컬 호스트에서 접근가능
 - % : 모든 원격 호스트 (로컬 호스트를 포함하지 않음)
 - 특정 IP : 특정 IP에서만 접근 가능
 - xxx.xxx.xxx.% : 특정 IP 대역에서만 접근 가능

 

2) 중요 권한 점검 (Y/N)
file_priv : 파일에 데이터를 읽고 쓸 수 있는 권한 (select, load)

( ex select * into outfile '/tmp/member.txt' from member; )
process_priv : mysql 서버 프로세스/스레드 정보를 보거나 중지시킬 수 있는 권한 (show processlist로 실시간 쿼리 모니터링)
shutdown_priv : mysql 서버를 종료시킬 수 있는 권한 (mysqladmin shutdown)

 

3) 보안패치 적용여부 점검
mysql -V 또는 --version

 

4) mysql 데이터 디렉토리 보호여부 점검

mysql은 테이블의 데이터 및 로그를 파일 형태로 관리한다.
my.cnf파일의 datadir가 데이터 디렉터리 경로이다.

 

권한 변경

chmod 750 /var/lib/mysql
또는
chmod g-w,o-rwx /var/lib/mysql

 

 

데이터베이스 보안 3 END --