제 이름은 Denis Rozhkov이고 Gazinformservice 회사의 제품 팀 소프트웨어 개발 책임자입니다. 자토바. 법률 및 기업 규정은 데이터 저장 보안에 대한 특정 요구 사항을 부과합니다. 누구도 제XNUMX자가 기밀 정보에 액세스하는 것을 원하지 않으므로 식별 및 인증, 데이터 액세스 관리, 시스템 정보 무결성 보장, 보안 이벤트 로깅 등의 문제는 모든 프로젝트에서 중요합니다. 그래서 저는 DBMS 보안과 관련하여 몇 가지 흥미로운 점에 대해 이야기하고 싶습니다.

이 기사는 다음의 연설을 바탕으로 작성되었습니다. @DatabasesMeetup, 조직 Mail.ru 클라우드 솔루션. 읽고 싶지 않다면 다음을 시청하세요.

이 기사는 세 부분으로 구성됩니다.

• 연결을 보호하는 방법.
• 작업 감사란 무엇이며 데이터베이스 측에서 발생하고 연결되는 상황을 기록하는 방법입니다.
• 데이터베이스 자체의 데이터를 보호하는 방법과 이에 사용할 수 있는 기술은 무엇입니까?

DBMS 보안의 세 가지 구성 요소: 연결 보호, 활동 감사 및 데이터 보호

연결 보안

웹 애플리케이션을 통해 직접 또는 간접적으로 데이터베이스에 연결할 수 있습니다. 일반적으로 비즈니스 사용자, 즉 DBMS를 다루는 사람은 간접적으로 DBMS와 상호 작용합니다.

연결 보호에 대해 이야기하기 전에 보안 조치가 어떻게 구성되는지 결정하는 중요한 질문에 답해야 합니다.

• 비즈니스 사용자 XNUMX명이 DBMS 사용자 XNUMX명과 동일합니까?
• DBMS 데이터에 대한 액세스가 귀하가 제어하는 ​​API를 통해서만 제공되는지, 아니면 테이블에 직접 액세스되는지 여부
• DBMS가 별도의 보호 세그먼트에 할당되었는지 여부, 누가 DBMS와 상호 작용하는지, 어떻게
• 풀링/프록시 및 중간 레이어가 사용되는지 여부는 연결 구축 방법과 데이터베이스를 사용하는 사람에 대한 정보를 변경할 수 있습니다.

이제 연결을 보호하는 데 어떤 도구를 사용할 수 있는지 살펴보겠습니다.

1. 데이터베이스 방화벽 클래스 솔루션을 사용하십시오. 추가 보호 계층은 최소한 DBMS에서 발생하는 작업의 투명성을 높이고 최대로 추가 데이터 보호를 제공할 수 있습니다.
2. 비밀번호 정책을 사용하세요. 용도는 아키텍처 구축 방법에 따라 다릅니다. 어떤 경우에도 DBMS에 연결되는 웹 애플리케이션의 구성 파일에 있는 비밀번호 하나만으로는 보호가 충분하지 않습니다. 사용자와 비밀번호를 업데이트해야 하는지 제어할 수 있는 다양한 DBMS 도구가 있습니다.

   사용자 평가 기능에 대해 자세히 알아볼 수 있습니다. 여기에, MS SQL 취약점 평가자에 대해서도 알아볼 수 있습니다. 여기에. 

3. 필요한 정보로 세션의 맥락을 풍부하게 만드세요. 세션이 불투명하고 해당 프레임워크 내에서 누가 DBMS에서 작업하고 있는지 이해할 수 없는 경우 수행 중인 작업 프레임워크 내에서 누가 무엇을 왜 수행하는지에 대한 정보를 추가할 수 있습니다. 이 정보는 감사에서 확인할 수 있습니다.
4. DBMS와 최종 사용자 사이에 네트워크 분리가 없고 별도의 VLAN에 있지 않은 경우 SSL을 구성하십시오. 이러한 경우 소비자와 DBMS 자체 간의 채널을 보호하는 것이 필수적입니다. 보안 도구는 오픈 소스에서도 사용할 수 있습니다.

이것이 DBMS 성능에 어떤 영향을 미치나요?

SSL이 CPU 로드에 어떤 영향을 미치고, 타이밍을 늘리고, TPS를 줄이는지, 활성화할 경우 너무 많은 리소스를 소비하는지 여부를 알아보기 위해 PostgreSQL의 예를 살펴보겠습니다.

pgbench를 사용하여 PostgreSQL을 로드하는 것은 성능 테스트를 실행하기 위한 간단한 프로그램입니다. 병렬 데이터베이스 세션에서 단일 명령 시퀀스를 반복적으로 실행한 다음 평균 트랜잭션 속도를 계산합니다.

SSL 없이 SSL을 사용하는 테스트 1 — 각 트랜잭션에 대해 연결이 설정됩니다.

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

SSL 없이 SSL을 사용하는 테스트 2 — 모든 트랜잭션은 하나의 연결에서 수행됩니다.

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

다른 설정:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

테스트 결과:

 
SSL 없음
SSL

모든 거래에 대해 연결이 설정됩니다.

대기 시간 평균
171.915 MS
187.695 MS

연결 설정을 포함한 tps
58.168112
53.278062

연결 설정을 제외한 tps
64.084546
58.725846

CPU
24%
28%

모든 트랜잭션은 하나의 연결로 수행됩니다.

대기 시간 평균
6.722 MS
6.342 MS

연결 설정을 포함한 tps
1587.657278
1576.792883

연결 설정을 제외한 tps
1588.380574
1577.694766

CPU
17%
21%

가벼운 부하에서 SSL의 영향은 측정 오류와 비슷합니다. 전송되는 데이터의 양이 매우 많으면 상황이 다를 수 있습니다. 트랜잭션당 하나의 연결을 설정하는 경우(드문 경우, 일반적으로 사용자 간에 연결이 공유됨) 연결/연결 끊김 수가 많아 영향이 조금 더 커질 수 있습니다. 즉, 성능 저하의 위험이 있을 수 있지만 보호 기능을 사용하지 않을 정도로 차이는 크지 않습니다.

작동 모드를 비교하면 큰 차이가 있다는 점에 유의하십시오. 동일한 세션 내에서 작업 중이거나 다른 세션에서 작업 중입니다. 이는 이해할 수 있습니다. 각 연결을 생성하는 데 리소스가 소비됩니다.

Zabbix를 신뢰 모드로 연결했을 때, 즉 md5가 확인되지 않아 인증이 필요하지 않은 경우가 있었습니다. 그런 다음 고객은 md5 인증 모드를 활성화하도록 요청했습니다. 이로 인해 CPU에 과도한 부하가 걸리고 성능이 저하되었습니다. 우리는 최적화 방법을 찾기 시작했습니다. 문제에 대한 가능한 해결책 중 하나는 네트워크 제한을 구현하고, DBMS에 대해 별도의 VLAN을 만들고, 누가 어디서 연결하는지 명확하게 하는 설정을 추가하고, 인증을 제거하는 것입니다. 인증 활성화 시 비용을 줄이기 위해 인증 설정을 최적화할 수도 있지만, 일반적으로 다양한 인증 방법을 사용하면 성능에 영향을 미치며 DBMS용 서버(하드웨어)의 컴퓨팅 성능을 설계할 때 이러한 요소를 고려해야 합니다.

결론: 여러 솔루션에서 인증의 작은 차이도 프로젝트에 큰 영향을 미칠 수 있으며 프로덕션 환경에서 구현될 때만 이것이 명확해지면 좋지 않습니다.

조치 감사

감사는 DBMS뿐만이 아닙니다. 감사는 다양한 부문에서 무슨 일이 일어나고 있는지에 대한 정보를 얻는 것입니다. 이는 데이터베이스 방화벽일 수도 있고 DBMS가 구축된 운영 체제일 수도 있습니다.

상업용 엔터프라이즈 수준 DBMS에서는 감사를 통해 모든 것이 정상이지만 오픈 소스에서는 항상 그런 것은 아닙니다. PostgreSQL의 기능은 다음과 같습니다.

• 기본 로그 - 내장된 로깅;
• 확장: pgaudit - 기본 로깅이 충분하지 않은 경우 별도의 설정을 사용하여 일부 문제를 해결할 수 있습니다.

영상의 보고서에 추가:

"기본 명령문 로깅은 log_statement = all을 사용하여 표준 로깅 기능으로 제공될 수 있습니다.

이는 모니터링 및 기타 용도로 허용되지만 일반적으로 감사에 필요한 세부 수준을 제공하지는 않습니다.

데이터베이스에서 수행되는 모든 작업의 ​​목록을 갖는 것만으로는 충분하지 않습니다.

또한 감사인이 관심을 가질 만한 특정 진술을 찾는 것도 가능해야 합니다.

표준 로깅은 사용자가 요청한 내용을 보여주고, pgAudit은 데이터베이스가 쿼리를 실행할 때 발생한 세부 사항에 중점을 둡니다.

예를 들어, 감사자는 문서화된 유지 관리 기간 내에 특정 테이블이 생성되었는지 확인하려고 할 수 있습니다.

이는 기본 감사 및 grep을 사용하는 간단한 작업처럼 보일 수 있지만 다음과 같은(의도적으로 혼란스러운) 예제가 표시되면 어떻게 될까요?

DO$$
BEGIN
EXECUTE 'CREATE TABLE 가져오기' || 'ant_table(id int)';
종료$$;

표준 로깅은 다음을 제공합니다.

로그: 명령문: DO $$
BEGIN
EXECUTE 'CREATE TABLE 가져오기' || 'ant_table(id int)';
종료$$;

테이블이 동적으로 생성되는 경우 관심 있는 테이블을 찾으려면 약간의 코드 지식이 필요할 수 있습니다.

단순히 테이블 이름으로 검색하는 것이 더 바람직하기 때문에 이는 이상적이지 않습니다.

이것이 pgAudit이 유용한 곳입니다.

동일한 입력에 대해 로그에 다음 출력이 생성됩니다.

감사: 세션,33,1,기능,DO,,,"DO $$
BEGIN
EXECUTE 'CREATE TABLE 가져오기' || 'ant_table(id int)';
END$$;"
감사: 세션,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table(ID INT)

DO 블록뿐만 아니라 명령문 유형, 객체 유형 및 전체 이름이 포함된 CREATE TABLE의 전체 텍스트도 기록되므로 검색이 더 쉽습니다.

SELECT 및 DML 문을 기록할 때 pgAudit은 문에서 참조되는 각 관계에 대해 별도의 항목을 기록하도록 구성할 수 있습니다.

특정 테이블과 관련된 모든 명령문을 찾기 위해 구문 분석이 필요하지 않습니다(*). "

이것이 DBMS 성능에 어떤 영향을 미치나요?

전체 감사를 활성화한 상태에서 테스트를 실행하고 PostgreSQL 성능에 어떤 일이 일어나는지 살펴보겠습니다. 모든 매개변수에 대해 최대 데이터베이스 로깅을 활성화해 보겠습니다.

구성 파일에서는 거의 아무것도 변경하지 않습니다. 가장 중요한 것은 최대 정보를 얻으려면 debug5 모드를 켜는 것입니다.

postgresql.conf

log_destination = 'stderr'
로깅_수집기 = 켜짐
log_truncate_on_rotation = 켜짐
log_rotation_age = 1일
log_rotation_size = 10MB
log_min_messages = 디버그5
log_min_error_statement = 디버그5
log_min_duration_statement = 0
debug_print_parse = 켜짐
debug_print_rewrite = 켜짐
debug_print_plan = 켜짐
debug_pretty_print = 켜짐
log_checkpoints = 켜짐
log_connections = 켜짐
log_disconnections = 켜짐
log_duration = 켜짐
log_hostname = 켜짐
log_lock_waits = 켜짐
log_replication_commands = 켜짐
log_temp_files = 0
log_timezone = '유럽/모스크바'

매개변수가 CPU 1개, 2,8GHz, 2GB RAM, 40GB HDD인 PostgreSQL DBMS에서 다음 명령을 사용하여 세 가지 로드 테스트를 수행합니다.

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

시험 결과:

로깅 없음
로깅 포함

총 데이터베이스 채우기 시간
43,74 초
53,23 초

램
24%
40%

CPU
72%
91%

테스트 1(50개 연결)

10분 동안의 거래 수
74169
32445

트랜잭션/초
123
54

평균 지연 시간
405 밀리 초
925 밀리 초

테스트 2(150개 연결 가능, 100개 가능)

10분 동안의 거래 수
81727
31429

트랜잭션/초
136
52

평균 지연 시간
550 밀리 초
1432 밀리 초

사이즈 정보

DB 크기
2251 MB
2262 MB

데이터베이스 로그 크기
0 Мб
4587 Мб

결론: 전체 감사는 그다지 좋지 않습니다. 감사 데이터는 데이터베이스 자체의 데이터만큼 크거나 그 이상입니다. DBMS 작업 시 생성되는 로깅의 양은 프로덕션 환경에서 흔히 발생하는 문제입니다.

다른 매개변수를 살펴보겠습니다.

• 속도는 크게 변하지 않습니다. 로깅 없음 - 43,74초, 로깅 포함 - 53,23초.
• 감사 파일을 생성해야 하므로 RAM 및 CPU 성능이 저하됩니다. 이는 생산성 측면에서도 두드러집니다.

연결 수가 늘어나면 당연히 성능이 조금씩 저하됩니다.

감사를 받는 기업에서는 더욱 어렵습니다.

• 데이터가 너무 많아요.
• SIEM의 syslog뿐만 아니라 파일에서도 감사가 필요합니다. syslog에 문제가 발생하면 데이터가 저장되는 데이터베이스에 가까운 파일이 있어야 합니다.
• 많은 공간을 차지하므로 I/O 디스크를 낭비하지 않도록 감사를 위해 별도의 선반이 필요합니다.
• 정보 보안 직원은 어디에서나 GOST 표준이 필요하며 국가 식별이 필요합니다.

데이터에 대한 액세스 제한

상용 DBMS와 오픈소스에서 데이터를 보호하고 접근하는 데 사용되는 기술을 살펴보자.

일반적으로 무엇을 사용할 수 있습니까?

1. 프로시저 및 함수의 암호화 및 난독화(래핑) - 즉, 읽을 수 있는 코드를 읽을 수 없게 만드는 별도의 도구 및 유틸리티입니다. 그렇다면 변경하거나 다시 리팩토링할 수 없습니다. 이 접근 방식은 적어도 DBMS 측에서는 때때로 필요합니다. 즉, 라이센스 제한 논리 또는 권한 부여 논리는 프로시저 및 기능 수준에서 정확하게 암호화됩니다.
2. 데이터 가시성을 행(RLS)으로 제한하는 것은 여러 사용자가 하나의 테이블을 볼 수 있지만 그 안의 행 구성이 다른 경우, 즉 행 수준에서 누군가에게 무언가를 표시할 수 없는 경우입니다.
3. 표시된 데이터를 편집(마스킹)하는 것은 테이블의 한 열에 있는 사용자가 데이터를 보거나 별표만 보는 경우입니다. 즉, 일부 사용자의 경우 정보가 닫힙니다. 이 기술은 액세스 수준에 따라 어떤 사용자에게 무엇을 표시할지 결정합니다.
4. 보안 DBA/애플리케이션 DBA/DBA 접근 제어는 오히려 DBMS 자체에 대한 접근을 제한하는 것입니다. 즉, 정보보안 담당자를 데이터베이스 관리자와 애플리케이션 관리자로 분리할 수 있습니다. 오픈소스에는 그러한 기술이 거의 없지만 상용 DBMS에는 그러한 기술이 많이 있습니다. 서버 자체에 액세스하는 사용자가 많을 때 필요합니다.
5. 파일 시스템 수준에서 파일에 대한 액세스를 제한합니다. 각 관리자가 필요한 데이터에만 액세스할 수 있도록 디렉터리에 대한 권한과 액세스 권한을 부여할 수 있습니다.
6. 필수 액세스 및 메모리 지우기 - 이러한 기술은 거의 사용되지 않습니다.
7. DBMS에서 직접 수행하는 종단 간 암호화는 서버 측에서 키를 관리하는 클라이언트 측 암호화입니다.
8. 데이터 암호화. 예를 들어, 열 기반 암호화는 데이터베이스의 단일 열을 암호화하는 메커니즘을 사용하는 경우입니다.

이것이 DBMS의 성능에 어떤 영향을 미치나요?

PostgreSQL의 열 암호화 예를 살펴보겠습니다. pgcrypto 모듈이 있어 선택한 필드를 암호화된 형식으로 저장할 수 있습니다. 일부 데이터만 가치 있는 경우에 유용합니다. 암호화된 필드를 읽기 위해 클라이언트는 암호 해독 키를 전송하고, 서버는 데이터를 암호 해독하여 클라이언트에 반환합니다. 키가 없으면 누구도 귀하의 데이터로 아무것도 할 수 없습니다.

pgcrypto로 테스트해보자. 암호화된 데이터와 일반 데이터가 포함된 테이블을 만들어 보겠습니다. 다음은 테이블을 생성하는 명령입니다. 첫 번째 줄에는 DBMS 등록을 통해 확장 자체를 생성하는 유용한 명령이 있습니다.

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

다음으로, 각 테이블에서 데이터 샘플을 만들어 실행 타이밍을 살펴보겠습니다.

암호화 기능이 없는 테이블에서 선택:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

스톱워치가 켜져 있습니다.

  아이디 | 텍스트1 | 텍스트2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000라인)

시간: 1,386ms

암호화 기능이 있는 테이블에서 선택:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

스톱워치가 켜져 있습니다.

  아이디 | 해독 | 해독하다
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000라인)

시간: 50,203ms

테스트 결과:

 
암호화 없이
Pgcrypto(암호해독)

1000개 행 샘플링
1,386 밀리 초
50,203 밀리 초

CPU
15%
35%

램
 
5%

암호화는 성능에 큰 영향을 미칩니다. 암호화된 데이터의 암호 해독 작업(및 암호 해독은 일반적으로 여전히 논리에 래핑되어 있음)에 상당한 리소스가 필요하기 때문에 타이밍이 늘어난 것을 볼 수 있습니다. 즉, 일부 데이터가 포함된 모든 열을 암호화한다는 아이디어는 성능 저하를 초래합니다.

그러나 암호화가 모든 문제를 해결하는 만능은 아닙니다. 데이터를 복호화하고 전송하는 과정에서 복호화된 데이터와 복호화 키는 서버에 보관됩니다. 따라서 시스템 관리자와 같이 데이터베이스 서버에 대한 전체 액세스 권한을 가진 사람이 키를 가로챌 수 있습니다.

모든 사용자의 전체 열에 대해 하나의 키가 있는 경우(모두는 아니지만 제한된 세트의 클라이언트의 경우) 이것이 항상 좋고 올바른 것은 아닙니다. 그렇기 때문에 그들은 엔드투엔드 암호화를 시작했고, DBMS에서는 클라이언트와 서버 측에서 데이터를 암호화하는 옵션을 고려하기 시작했으며 동일한 키 볼트 저장소가 나타났습니다. 즉, DBMS에서 키 관리를 제공하는 별도의 제품입니다. 옆.

MongoDB에서 이러한 암호화의 예

상용 및 오픈 소스 DBMS의 보안 기능

기능
유형
암호 정책
회계 감사
프로시저 및 함수의 소스 코드 보호
RLS
암호화

신탁
상업용
+
+
+
+
+

MsSQL
상업용
+
+
+
+
+

자토바
상업용
+
+
+
+
확장

PostgreSQL
무료
확장
확장
-
+
확장

몽고DB
무료
-
+
-
-
MongoDB Enterprise에서만 사용 가능

표는 완전하지 않지만 상황은 다음과 같습니다. 상용 제품에서는 보안 문제가 오랫동안 해결되었으며 오픈 소스에서는 일반적으로 보안을 위해 일종의 추가 기능이 사용되며 많은 기능이 누락되었습니다. , 때로는 뭔가를 추가해야 할 때도 있습니다. 예를 들어, 비밀번호 정책 - PostgreSQL에는 다양한 확장 기능이 있습니다(1, 2, 3, 4, 5), 비밀번호 정책을 구현하지만 제 생각에는 그 중 어느 것도 국내 기업 부문의 모든 요구를 충족하지 못합니다.

어디에도 필요한 것이 없다면 어떻게 해야 할까요?? 예를 들어, 고객이 요구하는 기능이 없는 특정 DBMS를 사용하고 싶습니다.

그런 다음 Crypto DB 또는 Garda DB와 같은 다양한 DBMS에서 작동하는 타사 솔루션을 사용할 수 있습니다. 국내 부문의 솔루션에 대해 이야기하고 있다면 오픈 소스보다 GOST에 대해 더 잘 알고 있습니다.

두 번째 옵션은 필요한 것을 직접 작성하고 애플리케이션의 프로시저 수준에서 데이터 액세스 및 암호화를 구현하는 것입니다. 사실, GOST를 사용하면 더 어려울 것입니다. 그러나 일반적으로 필요에 따라 데이터를 숨기고 DBMS에 넣은 다음 필요에 따라 애플리케이션 수준에서 바로 데이터를 검색하고 해독할 수 있습니다. 동시에 애플리케이션에서 이러한 알고리즘을 어떻게 보호할 것인지 즉시 생각해 보십시오. 우리 생각에는 이 작업이 더 빠르게 작동하기 때문에 DBMS 수준에서 수행되어야 합니다.

이 보고서는 에서 처음 발표되었습니다. @데이터베이스 모임 Mail.ru 클라우드 솔루션 제공. 바라보다 비디오 기타 공연 및 텔레그램 이벤트 공지사항 구독 Mail.ru 그룹의 Kubernetes 관련.

주제에 대해 더 읽을 내용:

1. Ceph 그 이상: MCS 클라우드 블록 스토리지.
2. 다시 선택할 필요가 없도록 프로젝트용 데이터베이스를 선택하는 방법.

출처 : habr.com