Data at Rest Encryption

개요

Table을 암호화하는 것은 누군가 접근하거나 하드디스크를 훔치고 원본데이터에 접근을 거의 불가능하게 만듭니다. 암호화 키들이 다른 시스템에 저장되어 있다고 가정합니다.

암호화를 사용하는 것은 대략 10% 의 오버헤드를 갖습니다.

어떤 스토리지 엔진이 암호화를 지원하는가 ?

순간, fully 암호화를 지원하는 엔진은 XtraDB and InnoDB 입니다. Aria storage engine 도 또한 암호화를 지원하지만, ROW_FORMAT=PAGE 로 생성한 테이블에 대해서만 지원합니다.(기본값)

MariaDB는 무엇을 암호화할지 사용자가 유연하게 구성하도록 허용합니다. XtraDB/InnoDB에서 모든것을 암호화를 위해 선택할 수 있습니다. — 모든 table space(모든 테이블)과 로그파일들 또는 하나의 table, 혹은 모든, 아니면 하나의 table을 뺀 것

Encryption key management

MariaDB 암호화는 다양한 암호화 키를 제공합니다. 그것들은 key identifier 에 의해 식별되어집니다. — 32-bit integer. 자동적인 key rotation 을 지원하기 위해 모든 키는 추가적으로 다른 versions을 가지고 있어야 합니다. XtraDB and InnoDB 는 자동적으로 데이터를 재 암호화 할 수 있습니다. 같은 키에 대한 오래된 버전에서 새로운 버전까지. 그러나 선택한 key managementsolution에 따라 key가 어떻게 저장되고 어떻게 순환되는 지 달라질 수 있습니다.

MariaDB 의 키 관리는 암호화 plugtin에 의해 제공 되어집니다. MariaDB는 file_key_management 라는 plugin을 포함하고 있습니다.

file_key_management plugin

이 file_key_management plugin 은 암호화 plugin으로 파일로부터 암호화 키를 읽습니다. 이 plugin은 다음과 같은 구성 옵션을 가지고 있습니다 :

• file_key_management_filename: 파일이 위치하는 곳, plugin은 요청 없이는 작동하지 않습니다.

• file_key_management_filekey: 키 파일을 복호화 하기 위한 옵션 키, 만약 키가 FILE: 로 시작한다면 나머지 값은 키를 가지고 있는 파일의 경로로 설명되어집니다.

• file_key_management_encryption_algorithm: 사용하기 위한 암호화 알고리즘

file_key_management_filename

키 파일은 세미콜론에 의해 분리된 암호화 키 식별자(32-bit numbers) 와 hex로 인코딩된 암호화 키를 포함합니다. 128, 192 또는 256 bit 키도 지원됩니다. Comment는 hash character로 시작됩니다.

# this is a comment
1;770A8A65DA156D24EE2A093277530142
18;F5502320F8429037B8DAEF761B189D12F5502320F8429037B8DAEF761B189D12

1 은 키 식별자로 table생성을 위해 사용되어 집니다. 이것은 hex로된 암호화 키 입니다.

키 식별자는 table마다 구분되어 집니다. 그러나 XtraDB/InnoDB 의 tablespace 와 로그파일은 항상 키 1을 사용합니다. 그리고 이것은 일반적으로 항상 존재합니다.

이 plugin은 key rotation을 지원하지 않습니다 — 모든 키는 항상 버전 1을 갖습니다.

만약 키 파일이 서버가 시작됐을 때 읽어지지 않았다면, 예를 들어 키 파일이 보이지 않는 다면, 암호화는 동작하지 않고 암호화된 테이블들은 읽어지지 않습니다.

file_key_management_filekey

키 파일은 암호화되어질 수 있습니다. 그리고 파일을 복호화하는 키는 옵션의 file_key_management_filekey 파라미터와 함께 주어집니다.

키 파일을 암호화하기 위해 OpenSSL 명령어 utility를 사용합니다. 예 :

openssl enc -aes-256-cbc -md sha1 -k secret -in keys.txt -out keys.enc

참고, -aes-256-cbc 와 sha1 를 사용해야하며 그렇지 않으면 plugin은 키 파일을 복호화 할 수 없음을 유의하십시오.

file_key_management_encryption_algorithm

이 plugin은 AES 와 다른block cipher modes를 사용하여 두 개의 암호화 알고리즘을 지원합니다.

file_key_management_encryption_algorithm 은 AES_CBC 또는 AES_CTR로 설정할 수 있습니다. 두번째로 — AES_CTR — 을 권장하지만, 항상 사용 가능하지는 않습니다. (최신 OpenSSL을 요구함). 만약 AES_CBC로 설정했다면, 이 plugin은 CBC 모드에서 128bit AES를 사용합니다. 만약 AES_CTR로 설정했다면, 이 plugin은 tablespace pages (InnoDB, XtraDB, and Aria)를 암호화하기 위해 CTR 모드에서 128bit AES를 사용합니다, 그리고 이는 임시파일들(암호문은 평문보다 커지도록 허용됩니다)을 위해 인증된 GCM 모드에서 AES를 사용합니다.

my.cnf file의 사용 예:

[mysqld]
file_key_management_encryption_algorithm=aes_cbc
file_key_management_filename = /home/mdb/keys.enc
file_key_management_filekey = secret

eperi Gateway for Databases

eperi는 MariaDB에 Key관리 및 암호화 솔루션을 제공합니다.

Key들은 key server에 저장되어지고 선택적으로 모든 암호화들은 key server에서 완료됩니다. 이는 file system을 접근한 공격자가 인증되지 않은 database file을 읽는 것으로부터 예방합니다 (see Why Encrypt MariaDB Data?).

The eperi Gateway for Databases provides the following key benefits: Databases를 위한 eperi Gateway는 다음과 같은 중요한 이점을 제공합니다:

• Database 외부 키 관리
• Databases server hard disk에 키들이 존재하지 않음
• 구성을 위한 사용자 그래픽 인터페이스
• Database외부의 암복호화, 최대의 보안을 위해 HSM 지원

Encrypting data

암호화가 가능하게 하기 위해서는 암호화 plugin을 실행해야 합니다. 예를 들어 file_key_management plugin. 이를 사용해 스토리지 엔진을 구성해야 합니다. 다음 정보는 스토리지 엔진의 상세 :

XtraDB and InnoDB

• Set innodb-encrypt-tables to ON or FORCE.
• Set innodb-encrypt-log to ON.

To fine-tune the encryption, you can use following variables: 암호화를 세부적으로 주려면 다음과 같은 변수들을 사용합니다 :

일반적으로 innodb-encrypt-log가 비활성화 중에 innodb-encrypt-tables만 사용할 수 없습니다. 이러한 설정에서 로그파일은 암호화되지 않은 data를 포함합니다. 반대의 경우, innodb-encrypt-log만 사용을 원한다면 innodb-encrypt-tables을 비활성화 시키고 ENCRYPTED=YES 옵션과 함께 table 당 암호화를 실행시킵니다.

또한, 임시 table에 대해 암호화를 사용하는 것도 좋은 생각입니다. (아래참조)

XtraDB 암호화를 사용한 my.cnf 예:

[mysqld]
plugin-load-add=file_key_management.so
file-key-management
file-key-management-filename = /mount/usb1/keys.txt
innodb-encrypt-tables
innodb-encrypt-log
innodb-encryption-threads=4

Specifying what tables to encrypt

어떤 table을 암호화할 것인지 선택할 수 있습니다. 속도에 견주어 보안을 허용할 수 있습니다.

table을 암호화하는 것은 CREATE TABLE 또는 ALTER TABLE 구문에 다음과 같은 옵션을 사용합니다:

Examples:

CREATE TABLE T (id int, value varchar(255)) ENCRYPTED=YES ENCRYPTION_KEY_ID=17;

table T를 key 17로 암호화하여 생성합니다.

ALTER TABLE T ENCRYPTED=YES ENCRYPTION_KEY_ID=18;

table T를 key18로 암호화하여 변경합니다. 만약 전에 암호화가 되어있었다면 우선 복호화한 다음에 다시 암호화합니다.

ALTER TABLE T encrypted=NO;

table T의 암호화를 비활성화 시킵니다. 만약 전에 암호화가 되어있었다면 복호화합니다.

관련있는 구성 변수:

Encryption of Aria tables

ROW_FORMAT=PAGE로 생성된 table들만 암호화될 수 있습니다. 이는 Aria에 대한 기본 row format입니다.

위 유형의 모든 Aria table이 명시된 것에 의해 암호화됨을 지정할 수 있습니다 :

[mysqld]
aria-encrypt-tables=1

Encryption of Aria temporary tables

MariaDB는 디스크에 기록되어 있는 임시 table들을 위해 Aria를 사용합니다. 임시 table들은 MEMORY table에 적합하지 않습니다.

Query실행의 일부로 생성된 임시 table들에 저장된 데이터를 아무도 접근할 수 없음을 보장하기 위해선 my.cnf파일에 지정하여 임시 데이터를 암호화할 수 있습니다 :

encrypt-tmp-disk-tables=1

이는 모든 새로운 임시 table에 대해 랜덤한 암호화키를 사용하고 생성됨으로써 작동합니다.

Encryption of temporary files

MariaDB might create temporary files on disk. For example, temporary files are created for binary log transactional caches and for filesort. Since 10.1.5 these temporary files are encrypted too if an encryption plugin is loaded (and no --disable-encrypt-tmp-files was specified on the command line or in the my.cnf file).

Encryption and compression

암호화된 압축(FusionIO로 사용가능한 기능)은 함께 사용되어집니다. 먼저 데이터를 압축한 다음 암호화합니다. 이런 경우 공간을 절약하고 여전히 데이터를 보호합니다.

Thanks

• Tablespace encryption was donated to the MariaDB project by Google.
• Per-table encryption and key identifier support was donated to the MariaDB project by eperi.

We are grateful to these companies for their support of MariaDB!

See Also

• Encryption functions
• DES_DECRYPT()
• DES_encrypt()
• A Blog post about table encryption with benchmark results