백업 암호화: 결승선에 도달하기

참고: 이 엔지니어링 게시물은 데이터베이스 관리자인 Silvia Botros가 작성했습니다. 여기에서 그녀의 다른 DBA 게시물을 확인하십시오.

1년 전 SendGrid는 SOC2 인증을 위해 열심히 노력했습니다. 모두가 참여했습니다. 우리 모두가 3분기 말까지 인증을 받으려고 했기 때문에 SOC2 태그가 있는 거의 모든 배송 팀 보드에 대한 이야기가 있었습니다. 상상할 수 있듯이 데이터베이스를 담당하는 사람으로서 스택의 해당 부분에 대해 해야 할 일이 분명히 있었습니다.

이 비즈니스 차원의 노력에 대한 나의 작업 목록은 백업이 암호화되었는지 확인하는 것이었습니다. 내가 친숙한 분야는 DBA 도구이고 Percona의 xtrabackup이 이미 암호화를 지원한다는 것을 알고 있기 때문에 이 작업의 첫 번째 시도로 그쪽으로 갈 것이라고 예상할 수 있었습니다.

이 접근 방식을 테스트하는 데 몇 가지 중요한 사항이 있었습니다.

• 분명히 백업을 암호화해야 했습니다.
• 백업 생성에 대한 오버헤드는 알려져 있고 수용 가능해야 함
• 복구 시 백업 암호 해독에 대한 오버헤드가 알려져 있어야 하고 수용 가능해야 함

즉, 먼저 백업에 걸리는 시간을 추적할 수 있어야 했습니다.

백업 시간 추적

SendGrid는 인프라 메트릭에 Graphite를 사용하고 대다수가 Sensu를 통해 전송되지만 Graphite는 bash 라인을 통해 직접 메트릭을 보낼 수 있을 만큼 쉽습니다. 백업 스크립트가 bash에 있기 때문에 매우 편리합니다. Graphite에서 직접 메트릭을 보내는 것은 확장성이 뛰어나지 않지만 이러한 백업은 최대 한 시간에 한 번 실행되기 때문에 제 필요에는 괜찮았습니다.

그 부분은 비교적 쉬웠다.

마지막 줄에서 무슨 일이 일어났는지 설명하기 위해 내가 보내는 메트릭의 경로(고유한지 확인), 메트릭 값, epoch 형식의 현재 시간을 Graphite에 보냅니다. Netcat은 단순성을 위해 사용하기로 결정한 것이며 1초의 시간 제한을 둡니다. 그렇지 않으면 절대 종료되지 않기 때문입니다. 'graphite url'은 데이터 센터의 Graphite에 대한 DNS 엔드포인트입니다.

이제 비교할 기준이 있으므로 암호화 방법 테스트를 시작할 준비가 되었습니다.

이 작업을 수행하는 방법에 대한 Percona의 자세한 문서에 따라 키를 만드는 것으로 시작했습니다. 해당 문서 페이지를 주의 깊게 읽으면 무언가를 깨달을 수 있습니다.

이 키는 백업 도구에 직접 전달되어야 하며 스냅샷을 해독할 수 있는 것과 동일한 키입니다. 이를 대칭 암호화라고 하며 양방향에서 동일한 키의 특성상 비대칭 암호화보다 덜 안전합니다. 단순함이 여전히 실행 가능한 접근 방식인지 확인하기 위해 테스트를 계속하기로 결정했습니다.

수백 MB의 매우 작은 DB를 사용한 테스트는 성공적이었습니다. 이 도구는 예상대로 작동하고 문서화되었지만 이는 기능 테스트에 더 가깝고 실제 질문은 "더 큰 DB에서 암호화에 따른 불이익의 크기는 얼마입니까?"였습니다. SendGrid의 더 많은 레거시 인스턴스는 1-2TB에서 단일 18TB 크기로 성장했습니다. 작은 인스턴스에 사용하려고 했던 것은 더 큰 인스턴스에서도 작동 가능해야 했습니다.

여기에서 테스트와 벤치마크가 흥미로워졌습니다.

상당한 크기의 첫 번째 테스트 대상은 디스크에 1TB인 데이터베이스입니다. 매우 빨리 예상치 못한 문제에 직면했습니다. 최소 암호화 설정(1 스레드, 기본 청크 크기)에서 다음 오류와 함께 백업이 실패하는 것을 보았습니다.

당시 이들 데이터베이스는 트랜잭션 로그 파일 크기로 512MB를 사용했고 이는 상당히 바쁜 클러스터여서 거의 1분마다 파일이 순환되고 있었습니다. 평소라면 DB 성능에서 눈에 띄겠지만 솔리드 스테이트 드라이브의 경이로움에 대부분 가려져 있었다. 병렬 암호화 스레드를 설정하지 않는 것처럼 보입니다(읽기: 하나 사용)는 `.ibd` 파일을 암호화하는 데 너무 많은 시간을 할애하여 우리 아래에서 실행되는 innodb 리두 로그가 백업 중단을 만들고 있음을 의미합니다.

따라서 여러 암호화 스레드를 사용하여 이를 다시 시도해 보겠습니다. 첫 번째 시도로 50개의 스레드로 시도했습니다. 여기서 비결은 CPU를 놓고 경쟁하지 않고 빠른 암호화의 장점을 찾는 것입니다. 또한 `ib_logfiles`의 크기를 각각 1GB로 늘렸습니다.

이것은 내가 하룻밤 동안 양조하게 해서 기뻤던 더 성공적인 테스트였습니다. 처음 며칠 밤에는 모든 것이 좋아 보였습니다. 많이 늘어나지 않는 백업을 할 때가 되었지만, 백업 과정 중 박스 로드 평균은 확실히 추가된 단계를 보여주고 있었습니다.

그러나 복원 테스트로 넘어갔을 때 암호화를 추가한 후 동일한 백업의 복원 프로세스가 60분에서 280분으로 증가했음을 발견했습니다. 이는 재해 발생 시 약속된 복구 시간에 심각한 불이익을 의미함을 의미합니다.

이를 보다 합리적인 기간으로 되돌려야 했습니다.

여기에 팀워크와 문제에 대한 더 간단한 솔루션이 빛을 발했습니다. InfoSec 팀원 중 한 명이 이 솔루션을 간소화할 수 있는지 알아보기로 했습니다. 그래서 그는 좀 더 테스트를 하고 더 간단하고 안전한 것으로 돌아왔습니다. 나는 아직 gpg2에 대해 배우지 않았기 때문에 이것은 나에게도 학습 연습이 되었다.

gpg2의 좋은 점은 비대칭 암호화를 지원한다는 것입니다. 비공개 및 공개 부분이 있는 키 쌍을 만듭니다. 공개 부분은 gpg2에 제공하기로 결정한 스트림 또는 파일을 암호화하는 데 사용되며 개인 비밀은 암호 해독에 사용할 수 있습니다.

여기에 암호화를 추가하기 위해 백업 스크립트를 변경했습니다. 읽기 쉽도록 일부 인수가 제거되었습니다.

반면에 백업을 복원할 때 허용되는 비밀 키가 호스트의 키 링에 있는지 확인한 다음 다음 명령을 사용하기만 하면 됩니다.

저도 gpg2가 처음이었기 때문에 이것은 저에게 배움의 기회가 되었습니다. 우리의 멋진 InfoSec 팀원인 Colin은 gpg2를 사용하면 다음을 포함하여 xtrabackup의 내장 압축을 사용할 때 여러 이점이 있음을 확인할 때까지 gpg2를 사용하여 백업 및 복원을 계속 테스트했습니다.

• 비대칭이었다
• 암호 해독을 위한 비밀 관리는 비교적 쉽게 순환됩니다(아래에서 자세히 설명).
• 그것은 도구에 구애받지 않습니다. 즉, xtrabackup을 사용하지 않는 다른 종류의 백업이 동일한 방법을 사용할 수 있음을 의미합니다.
• 복호화에 여러 코어를 사용하여 복원 시간을 단축했습니다.

항상 개선의 여지

여전히 개선의 여지가 있는 한 곳은 이러한 파일을 해독할 수 있는 비밀을 처리하는 방법입니다. 현재 엔터프라이즈 암호 관리 솔루션에 이러한 정보가 있지만 여기에서 가져온 다음 백업을 테스트하는 데 사용하는 것은 수동 프로세스입니다. 다음 계획은 Vault by Hashicorp를 구현하고 이를 사용하여 지정된 호스트에서 암호 해독을 위한 비밀 키를 가져온 다음 로컬 링에서 제거하여 자동화 테스트에 쉽게 사용할 수 있고 여전히 보호되도록 하는 것입니다.

궁극적으로 우리는 백업 성능이나 재해 복구 SLA를 희생하지 않으면서 SOC2 요구 사항을 적시에 준수할 수 있도록 모든 데이터베이스 백업을 확보했습니다. 저는 InfoSec 팀과 함께 이 과제를 수행하는 데 많은 재미를 느꼈고 새로운 도구를 배우면서 나왔습니다. 또한 가장 간단한 솔루션이 자신의 작업에 가장 적합할 때 항상 좋습니다.