MySQL의 암호화: 키 저장소

새로운 과정의 시작을 예상하여 "데이터 베이스" 당신을 위해 유용한 기사의 번역을 준비했습니다.

TDE(Transparent Data Encryption)가 등장했습니다. MySQL용 Percona 서버 그리고 꽤 오랫동안 MySQL. 그러나 TDE가 내부에서 어떻게 작동하는지, TDE가 서버에 어떤 영향을 미칠 수 있는지 생각해 본 적이 있습니까? 이 기사 시리즈에서는 TDE가 내부적으로 작동하는 방식을 살펴보겠습니다. 모든 암호화가 작동하는 데 필요하므로 키 저장소부터 시작하겠습니다. 그런 다음 Percona Server for MySQL/MySQL에서 암호화가 작동하는 방식과 Percona Server for MySQL에서 사용할 수 있는 추가 기능에 대해 자세히 살펴보겠습니다.

MySQL 키링

키링은 서버가 로컬 파일(keyring_file) 또는 원격 서버(예: HashiCorp Vault)에서 키를 쿼리, 생성 및 삭제할 수 있도록 하는 플러그인입니다. 키는 검색 속도를 높이기 위해 항상 로컬에 캐시됩니다.

플러그인은 두 가지 범주로 나눌 수 있습니다.

• 로컬 스토리지. 예를 들어 로컬 파일(이를 파일 기반 키링이라고 함)입니다.
• 원격 저장소. 예를 들어 Vault Server(서버 기반 키링이라고 함).

키를 저장하고 검색할 때뿐만 아니라 키를 시작할 때도 저장소 유형이 조금씩 다르기 때문에 이러한 분리가 중요합니다.

파일 저장소를 사용할 때 시작 시 저장소의 모든 콘텐츠(키 ID, 키 사용자, 키 유형 및 키 자체)가 캐시에 로드됩니다.

백엔드 저장소(예: Vault 서버)의 경우 시작 시 키 ID와 키 사용자만 로드되므로 모든 키를 가져와도 시작 속도가 느려지지 않습니다. 키가 느리게 로드됩니다. 즉, 키 자체는 실제로 필요할 때만 Vault에서 로드됩니다. 다운로드 후 키는 메모리에 캐시되므로 나중에 Vault 서버에 대한 TLS 연결을 통해 키에 액세스할 필요가 없습니다. 다음으로 키 저장소에 어떤 정보가 있는지 고려하십시오.

주요 정보에는 다음이 포함됩니다.

• 키 아이디 - 키 식별자, 예:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• 키 유형 - 사용된 암호화 알고리즘에 기반한 키 유형, 가능한 값: "AES", "RSA" 또는 "DSA".
• 키 길이 - 키 길이(바이트), AES: 16, 24 또는 32, RSA 128, 256, 512 및 DSA 128, 256 또는 384.
• 사용자 키의 소유자입니다. 키가 마스터 키와 같은 시스템 키인 경우 이 필드는 비어 있습니다. keyring_udf를 사용하여 키를 만든 경우 이 필드는 키 소유자를 나타냅니다.
• 키 그 자체

키는 key_id, user 쌍으로 고유하게 식별됩니다.

키 저장 및 삭제에도 차이가 있습니다.

파일 저장이 더 빠릅니다. 키 저장소가 파일에 대한 키의 일회성 쓰기라고 생각할 수 있지만 그렇지 않습니다. 여기에는 더 많은 작업이 있습니다. 파일 저장소가 수정될 때마다 모든 콘텐츠가 먼저 백업됩니다. 파일 이름이 my_biggest_secrets라고 가정하면 백업은 my_biggest_secrets.backup이 됩니다. 다음으로 캐시가 변경되고(키가 추가되거나 제거됨) 모든 것이 성공적이면 캐시가 파일로 덤프됩니다. 드물게 서버 충돌과 같은 경우에 이 백업 파일이 표시될 수 있습니다. 백업 파일은 다음에 키가 로드될 때(일반적으로 서버를 다시 시작한 후) 삭제됩니다.

서버 저장소에 키를 저장하거나 삭제할 때 저장소는 "키 보내기" / "키 삭제 요청" 명령으로 MySQL 서버에 연결해야 합니다.

서버 시작 속도로 돌아가 보겠습니다. 저장소 자체가 시작 속도에 영향을 미친다는 사실 외에도 시작 시 저장소에서 얼마나 많은 키를 가져와야 하는지에 대한 질문도 있습니다. 물론 이는 서버 스토리지에 특히 중요합니다. 시작할 때 서버는 암호화된 테이블/테이블스페이스에 필요한 키를 확인하고 스토리지에서 키를 요청합니다. 마스터 키가 있는 "깨끗한" 서버에는 암호화를 위한 하나의 마스터 키가 있어야 하며 스토리지에서 검색해야 합니다. 그러나 예를 들어 기본 서버의 백업이 대기 서버로 복원되는 경우 더 많은 키가 필요할 수 있습니다. 이 경우 마스터 키 순환을 제공해야 합니다. 이에 대해서는 향후 기사에서 더 자세히 설명하겠지만 여기에서는 특히 서버 키 저장소를 사용할 때 여러 마스터 키를 사용하는 서버를 시작하는 데 시간이 조금 더 걸릴 수 있다는 점에 유의하고 싶습니다.

이제 keyring_file에 대해 조금 더 이야기해 봅시다. keyring_file을 설계할 때 서버가 실행되는 동안 keyring_file 변경 사항을 확인하는 방법도 고민했습니다. 5.7에서는 이상적이지 않은 파일 통계를 기반으로 검사가 수행되었으며 8.0에서는 SHA256 체크섬으로 대체되었습니다.

keyring_file이 처음 실행될 때 파일 통계 및 체크섬이 서버에서 계산 및 기억되며 일치하는 경우에만 변경 사항이 적용됩니다. 파일이 변경되면 체크섬이 업데이트됩니다.

우리는 이미 키 저장소에 대한 많은 질문을 다루었습니다. 그러나 종종 잊어버리거나 오해하기 쉬운 또 다른 중요한 주제가 있습니다. 바로 서버 간 키 공유입니다.

내 말은? 클러스터의 각 서버(예: Percona 서버)는 Percona 서버가 해당 키를 저장해야 하는 Vault 서버에 별도의 위치가 있어야 합니다. 자격 증명 모음에 저장된 각 마스터 키에는 해당 ID 내에 Percona 서버 GUID가 포함되어 있습니다. 왜 중요 함? Vault 서버가 하나만 있고 클러스터의 모든 Percona 서버가 이 단일 Vault 서버를 사용한다고 가정합니다. 문제는 명백해 보인다. 모든 Percona 서버가 고유 식별자가 없는 마스터 키(예: id = 1, id = 2 등)를 사용한 경우 클러스터의 모든 서버는 동일한 마스터 키를 사용합니다. 이것이 GUID가 제공하는 것, 즉 서버 간의 구별입니다. 그렇다면 이미 고유한 GUID가 있는 경우 서버 간 키 공유에 대해 이야기하는 이유는 무엇입니까? keyring_udf라는 또 다른 플러그인이 있습니다. 이 플러그인을 사용하면 서버 사용자가 Vault 서버에 키를 저장할 수 있습니다. 문제는 사용자가 예를 들어 server1에서 키를 만든 다음 server2에서 동일한 ID로 키를 만들려고 할 때 발생합니다. 예를 들면 다음과 같습니다.

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

기다리다. 두 서버 모두 동일한 Vault 서버를 사용합니다. keyring_key_store 기능이 server2에서 실패하면 안 됩니까? 흥미롭게도 동일한 서버에서 동일한 작업을 수행하려고 하면 오류가 발생합니다.

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

맞습니다. ROB_1은 이미 존재합니다.

먼저 두 번째 예를 살펴보겠습니다. 앞서 말했듯이 keyring_vault 또는 다른 볼트 플러그인(keyring)은 모든 키 ID를 메모리에 캐시합니다. 따라서 새 키를 생성한 후 ROB_1이 server1에 추가되고 이 키를 Vault로 보내는 것 외에 캐시에도 키가 추가됩니다. 이제 동일한 키를 두 번째로 추가하려고 하면 keyring_vault는 키가 캐시에 있는지 확인하고 오류를 발생시킵니다.

첫 번째 경우에는 상황이 다릅니다. Server1과 server2에는 별도의 캐시가 있습니다. ROB_1을 server1 및 Vault 서버의 키 캐시에 추가한 후 server2의 키 캐시가 동기화되지 않습니다. server2의 캐시에 ROB_1 키가 없습니다. 따라서 ROB_1 키는 keyring_key_store와 Vault 서버에 기록되며 실제로 이전 값을 덮어씁니다(!). 이제 Vault 서버의 ROB_1 키는 543210987654321입니다. 흥미롭게도 Vault 서버는 이러한 작업을 차단하지 않고 이전 값을 쉽게 덮어씁니다.

이제 keyring_udf를 사용하고 Vault에 키를 저장하려는 경우 Vault에서 서버별 분리가 중요한 이유를 알 수 있습니다. Vault 서버에서 이러한 분리를 제공하는 방법은 무엇입니까?

Vault에서 분할하는 방법에는 두 가지가 있습니다. 각 서버에 대해 다른 마운트 지점을 만들거나 동일한 마운트 지점 내에서 다른 경로를 사용할 수 있습니다. 이를 보여주는 가장 좋은 방법은 예제를 사용하는 것입니다. 먼저 개별 마운트 지점을 살펴보겠습니다.

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

여기에서 server1과 server2가 서로 다른 마운트 지점을 사용함을 알 수 있습니다. 경로 분리를 사용하면 구성은 다음과 같습니다.

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

이 경우 두 서버 모두 동일한 마운트 지점 "mount_point"를 사용하지만 경로는 다릅니다. 이 경로를 사용하여 server1에서 첫 번째 비밀을 생성하면 Vault 서버가 자동으로 "server1" 디렉토리를 생성합니다. server2의 경우 모든 것이 동일합니다. mount_point/server1 또는 mount_point/server2에서 마지막 암호를 삭제하면 Vault 서버도 해당 디렉터리를 삭제합니다. 분할 경로를 사용하는 경우 마운트 지점을 하나만 만들고 서버가 별도의 경로를 사용하도록 구성 파일을 변경해야 합니다. 마운트 지점은 HTTP 요청으로 생성할 수 있습니다. CURL을 사용하면 다음과 같이 수행할 수 있습니다.

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

모든 필드(TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT)는 구성 파일의 매개변수에 해당합니다. 물론 Vault 유틸리티를 사용하여 동일한 작업을 수행할 수 있습니다. 그러나 마운트 지점 생성을 자동화하는 것이 더 쉽습니다. 이 정보가 도움이 되기를 바라며 이 시리즈의 다음 기사에서 뵙겠습니다.

더 읽어보기:

• 무작위 변수의 Sysbench 및 분포

출처 : habr.com