SQL Server TDE를 사용하여 원격 백업을 작성할 때 네트워크 트래픽이 암호화됩니까?


9

그들은“멍청한 질문”과 같은 것은 없다고 말하므로 여기에 간다.

SQL Server TDE ( 투명한 데이터 암호화 )는 유휴 데이터를 암호화하므로 누군가 저장소에 침입하여 해당 파일을 훔치면 데이터베이스 파일 (.mdf)과 백업 파일 (.bak)이 암호화됩니다. 또한 데이터를 디스크에서 읽을 때 데이터가 해독되어 메모리에서 암호화되지 않도록합니다 (움직임). 따라서 원격 쿼리를 실행하는 사용자 (SensitiveData에서 선택 *)가 요청한 데이터는 네트워크를 통해 이동할 때 암호화되지 않으므로 인터셉트하기 쉽습니다.

따라서 위의 모든 사항이 정확하다고 가정하면 바보 같은 질문입니다 .SQL Server 인스턴스가 컴퓨터 A에 있고 TDE 데이터베이스 백업이 원격 컴퓨터 B의 저장소에 기록되는 경우 백업 작업 데이터는 다음과 같이 암호화됩니다. 컴퓨터 A가 컴퓨터 B의 디스크에 기록 될 것인가? 암호화 작업은 컴퓨터 A에서 먼저 발생한다고 가정하기 때문에 Microsoft 설명서 또는 블로그에서 확인할 수 없습니다. 마찬가지로 복원 작업 중에 컴퓨터 B의 디스크에서 전송되는 데이터를 가로 채서 컴퓨터 A의 데이터베이스를 복원하는 사람이 있었습니까?


2
정말 좋은 질문입니다
Shanky

답변:


7

예. TDE 데이터는 디스크에서 암호화되므로 백업 작업은 네트워크를 통해 이동하는 동안 백업이 암호화 되지 않습니다 .

폴 랜달의 백업 신화 :

신화 30-09) 백업은 버퍼 풀을 통해 데이터를 읽습니다.

아니요 . 백업 하위 시스템은 데이터베이스 파일에 대한 자체 채널을 열어서 SQL Server의 메모리로 모든 것을 읽고 백업 장치로 다시 가져와야하는 성능 저하를 방지합니다 (또한 프로세스에서 버퍼 풀을 효과적으로 플러시). 페이지 체크섬 검사를 요청하면 자체 메모리의 작은 부분을 사용합니다.

페이지가 버퍼 풀에로드 된 경우 (SQL이 데이터베이스 테이블 및 인덱스 데이터를 캐시하는 데 사용하는 "정상"메모리 공간) 해독해야합니다. 그러나 백업은 그렇게하지 않으며, 암호화 된 "익스텐트"(연속 8 페이지 청크)를 백업 대상으로 덤프합니다.

Paul Randal로부터 위의 의견이 여전히 TDE와 관련이 있음을 확인할 수있었습니다 .

정확히 같은 방식으로 작동합니다. 버퍼 풀은 암호화를 수행 한 다음 페이지를 디스크에 쓰기 전에 페이지 체크섬을 추가합니다. 백업 은 버퍼 풀을 통해 읽지 않습니다 . 예, TDE 데이터베이스의 백업에는 여전히 암호화가 있습니다. 페이지 체크섬의 유효성은 검사되지만 버퍼 풀 코드가 아닌 백업 코드로 확인됩니다.

다시 말해, 데이터베이스에서 CHECKSUM을 활성화 한 경우 암호화가 수행 된 (일반 SQL 쓰기 작업 중) 추가 됩니다. 이는 백업 프로세스가 데이터를 해독하지 않고 원시 (암호화 된) 범위를 읽고, 체크섬을 검증하고, 백업을 쓸 수 있음을 의미합니다.

이것은 암호화 된 데이터가 압축 할 수 없기 때문에 (SQL 2016 이전) TDE로 데이터베이스에서 백업 압축을 사용하여 아무것도 수행하지 않은 이유는 거의 확실합니다 .

이는 TDE 암호화 데이터베이스의 백업을 수행 할 때 데이터베이스 페이지가 백업 될 때 해독되지 않기 때문입니다. 이들은 일반적으로있는 것과 동일한 암호화 상태로 백업 된 다음 압축 됩니다. 본질적으로 암호화 된 데이터는 매우 독특하므로 데이터 압축은 암호화 된 데이터에 대해별로 좋지 않습니다.

복원 작업의 경우 동일한 원칙이 적용됩니다. 암호화 된 백업은 네트워크를 통해 암호화 된 상태로 유지되며 여전히 암호화 된 상태로 복원 서버의 디스크에 기록됩니다. 복원이 완료된 후 데이터베이스가 메모리에로드 될 때만 해독됩니다.


3

... 컴퓨터 A에서 컴퓨터 B로 디스크에 기록 될 때 백업 작업 데이터가 암호화됩니까?

예, 버퍼 풀에 들어가면 암호가 해독되고 나가면 암호화됩니다. 이 상황에서 우리는 디스크에 기록하기 때문에 먼저 암호화 된 다음 기록됩니다. 쓰기는 네트워크를 통해 이루어 지므로 데이터 자체는 암호화되지만 네트워크 트래픽의 다른 부분은 암호화되지 않습니다.

... 복원 작업 중 ... 데이터가 이동 중 암호화 된 것을 발견합니까?

예, 위와 동일하지만 역순으로 적용되기 때문입니다. 데이터가 디스크에서 암호화되어 암호화 된 상태로 읽고 전송됩니다. 그런 다음 인스턴스로 이동하여 버퍼 풀에로드되어 도중에 단계적으로 암호화되지 않습니다.


1
나는 이것이 옳다고 생각하지만, 당신이 말하는 이유가 정확하지는 않습니다. BACKUP은 원시 데이터베이스 EXTENTS (페이지가 아닌)를 디스크로 보내서 메모리에로드 될 때 해독 단계를 무시할 것이라고 생각했습니다. 잘못되었을 수도 있지만 지금 설명서를 찾고 있습니다.
BradC

1
Paul Randal의 신화 30-09를 참조하십시오 . "백업 서브 시스템은 모든 것을 SQL Server의 메모리로 읽어 백업 장치로 다시 읽어야하는 성능 저하를 피하기 위해 데이터베이스 파일에 대한 자체 채널을 엽니 다". TDE를 구체적으로 언급하지는 않지만 백업 프로세스가 자체 채널 인 경우 즉시 재 암호화하는 것만으로도 암호 해독이 낭비되는 것 같습니다. CHECKSUMS의 유효성을 검사하거나 암호 해독없이 압축을 적용 할 수도 있습니다.
BradC

@BradC 백업 자체가 이런 식으로 작동한다고 말하지는 않았지만 암호화 / 암호 해독 프로세스가 유휴 데이터에서 작동하는 방식에 대해서는 말하지 않았습니다. 모호한 경우 변경하지만 암호화 / 암호 해독이 발생하는 시점과 장소에서 백업이 작동하는 방식은 아닙니다.
Sean Gallardy

그러나 백업 프로세스가 버퍼 풀을 사용하지 않는 경우 결론 (백업 패킷이 암호화 됨)이 다른 이유로 올바른 경우에도 추론이 올바르지 않습니다.
BradC

@BradC 아니요, 추론은 디스크에 이미 기록되어 있으므로 이미 암호화되어 있다는 것입니다. 백업이 해독되었다는 것을 어떻게 알 수 있는지 확실하지 않은 경우 BP를 통해 다시 암호화됩니다. 이미 암호화되어 있다고 말하면 다른 디스크로 복사하거나 다른 디스크에서 복사해도 암호가 해독되지 않는다고 생각했습니다. 어떻게 혼동하는지 잘 모르겠습니다.
Sean Gallardy 17 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.