MySQL의 암호화: 마스터 키 사용

새로운 과정의 시작을 예상하여 "데이터 베이스" 우리는 MySQL의 암호화에 대한 일련의 기사를 계속 게시합니다.

이 시리즈의 이전 기사(MySQL의 암호화: 키 저장소) 키 자격 증명 모음에 대해 이야기했습니다. 이번 글에서는 마스터 키가 어떻게 사용되는지 살펴보고 봉투 암호화의 장점과 단점에 대해 논의하겠습니다. 

봉투 암호화의 기본 아이디어는 암호화에 사용되는 키(테이블스페이스 키)가 다른 키(마스터 키)로 암호화된다는 것입니다. 테이블스페이스 키는 실제로 데이터를 암호화하는 데 사용됩니다. 그래픽적으로는 다음과 같이 표현할 수 있습니다.

마스터 키는 키링에 있고 테이블스페이스 키는 암호화된 테이블스페이스 헤더(테이블스페이스의 0페이지)에 있습니다. 

위 그림에서:

• 테이블 A는 키 1(키 1)로 암호화됩니다. 키 1은 마스터 키를 사용하여 암호화되어 테이블 A의 헤더에 암호화되어 저장됩니다.

• 테이블 B는 키 2로 암호화됩니다. 키 2는 마스터키(마스커키)를 이용해 암호화되어 테이블 B의 헤더에 암호화되어 저장된다.

• 등등.

서버가 테이블 A를 해독해야 하는 경우 스토리지에서 마스터 키를 검색하고, 테이블 A의 헤더에서 암호화된 키 1을 읽고, 키 1을 해독합니다. 해독된 키 1은 서버의 메모리에 캐시되어 테이블 A를 해독하는 데 사용됩니다. .

InnoDB

InnoDB에서 실제 암호화 및 복호화는 I/O 계층에서 수행됩니다. 즉, 페이지는 디스크에 플러시되기 직전에 암호화되고 디스크에서 읽힌 직후에 암호가 해독됩니다.

InnoDB에서 암호화는 테이블스페이스 수준에서만 작동합니다. 그리고 기본적으로 모든 테이블은 별도의 테이블스페이스(테이블당 파일 테이블스페이스). 즉, 하나의 테이블만 포함할 수 있는 테이블스페이스가 생성됩니다. 기본 테이블스페이스에도 테이블을 생성할 수 있지만(일반 테이블스페이스). 그러나 어떤 경우에도 테이블은 항상 일부 테이블스페이스에 위치합니다. 그리고 테이블스페이스 레벨에서 암호화가 이루어지기 때문에 완전히 암호화되거나 그렇지 않은 경우가 있습니다. 즉, 메인 테이블스페이스의 테이블 중 일부만을 암호화하는 것은 불가능하다. 

어떤 이유로 테이블당 파일을 비활성화하면 모든 테이블이 시스템 테이블스페이스 내에 생성됩니다. 안에 MySQL용 Percona 서버 innodb 변수를 사용하여 시스템 테이블스페이스를 암호화할 수 있습니다.sys테이블스페이스암호화 스레드를 암호화하거나 사용하지만 이는 아직 실험적인 기능입니다. MySQL에는 이것이 없습니다.

계속 진행하기 전에 마스터 키 ID의 구조를 살펴봐야 합니다. UUID, KEY로 구성됩니다.ID 및 접두사 "INNODBKey". 다음과 같습니다: INNODBKey-UUID-KEYID.

UUID는 암호화된 테이블스페이스가 있는 서버의 uuid입니다. 열쇠ID는 단순히 계속 증가하는 값입니다. 마스터키 KEY를 처음 생성할 때ID는 1입니다. 키 순환 중 새 마스터 키가 생성되면 KEYID = 2 등입니다. 이 시리즈의 다음 기사에서 마스터 키 순환에 대해 자세히 설명하겠습니다.

이제 마스터 키 식별자가 어떻게 생겼는지 알았으니 암호화된 테이블스페이스 헤더를 살펴보겠습니다. 테이블스페이스가 암호화되면 헤더에 암호화 정보가 추가됩니다. 다음과 같습니다.

키 ID는 KEY입니다.이미 논의한 마스터 키 ID의 ID입니다. UUID는 서버의 uuid이며 마스터 키 식별자에도 사용됩니다. TABLESPACE KEY - 서버에서 무작위로 생성된 256비트로 구성된 테이블스페이스 키입니다. 초기화 벡터(IV)도 무작위로 생성된 256비트로 구성됩니다(128비트여야 함). IV는 AES 암호화 및 복호화를 초기화하는 데 사용됩니다(256비트 중 128비트만 사용됨). 마지막에는 TABLESPACE KEY 및 IV에 대한 CRC32 체크섬이 있습니다.

지금까지 나는 헤더에 테이블스페이스의 암호화된 키가 포함되어 있다고 조금 단순화했습니다. 실제로 테이블스페이스 키와 초기화 벡터는 마스터 키를 사용하여 함께 저장되고 암호화됩니다. 테이블스페이스 키와 초기화 벡터를 암호화하기 전에 이에 대한 CRC32가 계산된다는 점을 기억하십시오.

CRC32가 왜 필요한가요?

간단히 말해서, 마스터 키의 유효성을 보장합니다. 테이블스페이스 키와 초기화 벡터를 복호화한 후 체크섬을 계산하여 헤더에 저장된 CRC32와 비교합니다. 체크섬이 일치하면 올바른 마스터 키와 테이블스페이스 키가 있는 것입니다. 그렇지 않으면 테이블스페이스가 누락된 것으로 표시됩니다(어차피 해독할 수 없습니다).

다음과 같이 질문할 수 있습니다. 키 검증은 어느 시점에 수행됩니까? 대답은 서버가 시작될 때입니다. 암호화된 테이블/테이블스페이스가 있는 서버는 시작 시 UUID, KEY를 읽습니다.헤더에서 ID를 가져와 마스터 키 ID를 생성합니다. 그런 다음 키링에서 필요한 마스터 키를 얻고, 테이블스페이스 키를 해독하고, 체크섬을 확인합니다. 다시 한 번 체크섬이 일치하면 모든 것이 정상이며, 일치하지 않으면 테이블스페이스가 누락된 것으로 표시됩니다.

이 시리즈의 이전 기사(MySQL의 암호화: 키 저장소), 그러면 서버 기반 키 저장소를 사용할 때 시작 시 서버가 키 식별자 목록, 즉 키 ID와 사용자 ID만 수신한다는 점을 기억할 수 있습니다. 이 쌍은 키를 고유하게 식별하기 때문입니다. 이제 서버가 시작되면 테이블스페이스 키를 해독할 수 있는지 확인하는 데 필요한 모든 키를 수신한다는 의미입니다. 그런데 왜 초기화 과정에서 서버 스토리지의 경우 키만 로드되나요?아이디와 사용자ID가 아닌 모든 키가 있습니까? 모든 키가 필요하지 않을 수도 있기 때문입니다. 이는 주로 마스터 키 순환으로 인해 발생합니다. 마스터 키가 순환되면 저장소에 새 마스터 키가 생성되지만 이전 키는 삭제되지 않습니다. 따라서 서버에 필요하지 않은 많은 키가 서버 키 저장소에 있을 수 있으므로 서버가 시작될 때 검색되지 않습니다.

이제 마스터 키 암호화의 장점과 단점에 대해 조금 이야기할 시간입니다. 가장 큰 장점은 암호화된 데이터와 별도로 저장되는 암호화 키(마스터 키)가 하나만 필요하다는 것입니다. 이를 통해 서버 시작이 빠르고 저장 공간이 작아 관리가 쉬워집니다. 또한 단일 마스터 키는 재생성하기도 쉽습니다.

그러나 마스터 키 암호화에는 한 가지 큰 단점이 있습니다. 테이블스페이스가 tablespace_key로 암호화되면 항상 동일한 키로 암호화된 상태로 유지됩니다. 여기서는 마스터 키를 순환하는 것이 도움이 되지 않습니다. 이것이 왜 단점입니까? 우리는 MySQL에 갑작스러운 충돌과 코어 파일 생성으로 이어질 수 있는 버그가 있다는 것을 알고 있습니다. 코어 파일에는 서버 메모리 덤프가 포함되어 있으므로 덤프에 해독된 테이블스페이스 키가 포함될 수 있습니다. 설상가상으로, 해독된 테이블스페이스 키는 메모리에 저장되어 디스크로 교체될 수 있습니다. 이러한 파일과 스왑 파티션에 액세스하려면 루트 권한이 필요하므로 이는 단점이 아니라고 말할 수 있습니다. 예. 그러나 루트는 잠시 동안만 필요합니다. 누군가가 해독된 테이블스페이스 키에 액세스하면 루트 권한 없이도 이를 사용하여 데이터를 해독할 수 있습니다. 또한 디스크를 도난당할 수 있으며, 타사 도구를 사용하여 스왑 파티션/코어 파일을 읽을 수 있습니다. TDE의 목표는 디스크를 도난당하더라도 읽을 수 없도록 만드는 것입니다. 안에 MySQL용 Percona 서버 새로 생성된 키를 사용하여 테이블스페이스를 다시 암호화할 수 있습니다. 이 기능을 암호화 스레드라고 하며 이 글을 쓰는 시점에서는 아직 실험적입니다.

과정에 대해 자세히 알아보기

더 읽어보기:

• MySQL의 암호화: 키 저장소

출처 : habr.com