Lưu lượng mạng có được mã hóa khi viết các bản sao lưu từ xa bằng SQL Server TDE không?


9

Họ nói rằng không có câu hỏi nào về câu hỏi ngu ngốc của người Viking, vì vậy hãy đến đây:

Tôi hiểu rằng Mã hóa dữ liệu trong suốt của SQL Server (TDE) mã hóa dữ liệu khi nghỉ, để các tệp cơ sở dữ liệu của bạn (.mdf) và các tệp sao lưu của bạn (.bak) được mã hóa nếu ai đó xâm nhập vào bộ lưu trữ của bạn và đánh cắp các tệp đó. Tôi cũng hiểu rằng dữ liệu được giải mã khi đọc từ đĩa để không bị mã hóa trong bộ nhớ (trong chuyển động). Do đó, dữ liệu được yêu cầu bởi người dùng đang chạy truy vấn từ xa (chọn * từ SensitiveData) sẽ không được mã hóa khi di chuyển qua mạng và do đó dễ bị chặn.

Vì vậy, giả sử tất cả những điều trên là chính xác, đây là câu hỏi ngu ngốc của tôi: Nếu phiên bản SQL Server của tôi nằm trên máy tính A và các bản sao lưu cơ sở dữ liệu TDE của tôi bị xóa để lưu trữ trên máy tính từ xa B, là dữ liệu hoạt động sao lưu được mã hóa khi nó di chuyển từ máy tính A được ghi vào đĩa tại máy tính B? Tôi giả sử nó phải như vậy (vì tôi cho rằng hoạt động mã hóa xảy ra trên máy tính A trước tiên), nhưng tôi không thể tìm thấy xác nhận điều này trong bất kỳ tài liệu nào của Microsoft hoặc trên blog. Và tương tự, trong quá trình khôi phục - có ai chặn dữ liệu được truyền từ đĩa tại máy tính B để khôi phục cơ sở dữ liệu ở máy tính A - họ có thấy dữ liệu đó được mã hóa không?


2
Đây thực sự là một câu hỏi hay
Shanky

Câu trả lời:


7

Có, các bản sao lưu được mã hóa trong khi di chuyển qua mạng vì dữ liệu TDE được mã hóa trên đĩa và hoạt động sao lưu không bao giờ giải mã nó .

Huyền thoại dự phòng của Paul Randal :

Chuyện lầm tưởng 30-09) sao lưu đọc dữ liệu qua vùng đệm

Không. Hệ thống con sao lưu mở các kênh riêng của nó vào các tệp cơ sở dữ liệu để tránh bị ảnh hưởng khi phải đọc mọi thứ vào bộ nhớ của SQL Server và quay trở lại thiết bị sao lưu (và cũng có hiệu quả xóa sạch vùng đệm trong quy trình). Nếu bạn yêu cầu kiểm tra tổng kiểm tra trang, nó sẽ sử dụng một phần bộ nhớ nhỏ.

Nếu các trang được tải vào nhóm bộ đệm (không gian bộ nhớ "bình thường" mà SQL sử dụng để lưu trữ dữ liệu chỉ mục và bảng cơ sở dữ liệu), chúng sẽ phải được giải mã. Nhưng các bản sao lưu không làm được điều đó, họ chỉ chuyển các "phạm vi" được mã hóa thô (các đoạn 8 trang liền kề) đến đích sao lưu của bạn.

Tôi đã có thể nhận được xác nhận từ Paul Randal rằng nhận xét trên của anh ấy vẫn phù hợp với TDE :

Nó hoạt động chính xác theo cùng một cách. Nhóm bộ đệm thực hiện mã hóa sau đó thêm một tổng kiểm tra trang trước khi ghi một trang vào đĩa. Sao lưu không bao giờ đọc qua vùng đệm. Vì vậy, có, một bản sao lưu của cơ sở dữ liệu TDE vẫn còn mã hóa trong đó. Tổng kiểm tra trang được xác thực, nhưng bằng mã dự phòng, không phải mã nhóm bộ đệm.

Nói cách khác, nếu bạn đã kích hoạt CHECKSUM trên cơ sở dữ liệu, chúng sẽ được thêm vào (trong các hoạt động ghi SQL thông thường) sau khi mã hóa xảy ra. Điều này có nghĩa là quá trình sao lưu có thể đọc phạm vi thô (được mã hóa), xác thực tổng kiểm tra và viết bản sao lưu, tất cả mà không cần giải mã dữ liệu.

Đây gần như chắc chắn là lý do (trước SQL 2016), cho phép nén sao lưu trên cơ sở dữ liệu với TDE không làm gì cả, vì dữ liệu được mã hóa không thể nén được :

Điều này là do khi sao lưu cơ sở dữ liệu được mã hóa TDE, các trang cơ sở dữ liệu không được giải mã khi sao lưu. Chúng được sao lưu trong trạng thái được mã hóa giống như bình thường, sau đó được nén . Do bản chất, dữ liệu được mã hóa rất độc đáo nên việc nén dữ liệu không giúp ích nhiều cho dữ liệu được mã hóa.

Đối với một hoạt động khôi phục, nguyên tắc tương tự được áp dụng. Bản sao lưu được mã hóa vẫn được mã hóa trên mạng và được ghi vào đĩa của máy chủ khôi phục ở trạng thái vẫn được mã hóa. Chúng chỉ được giải mã khi cơ sở dữ liệu được tải trong bộ nhớ sau khi khôi phục hoàn tất.


3

... Dữ liệu hoạt động sao lưu được mã hóa khi nó di chuyển từ máy tính A để ghi vào đĩa tại máy tính B?

Vâng, nó được giải mã khi nó vào vùng đệm và được mã hóa khi nó rời đi. Trong tình huống này vì chúng ta đang ghi vào đĩa, nó được mã hóa trước và sau đó được viết. Vì việc ghi đang đi qua mạng, dữ liệu được mã hóa nhưng bất kỳ phần nào khác của lưu lượng truy cập mạng thì không.

... trong quá trình khôi phục ... họ có thấy dữ liệu đó được mã hóa không?

Có, vì tương tự như trên áp dụng nhưng theo thứ tự ngược lại. Dữ liệu được mã hóa trên đĩa, đang được đọc và chuyển ở trạng thái được mã hóa. Sau đó, nó được đưa vào thể hiện và được tải vào vùng đệm nơi nó không được mã hóa như một bước trên đường.


1
Tôi nghĩ điều này là đúng, nhưng tôi không chắc rằng nó đúng vì những lý do bạn nói. Tôi nghĩ rằng BACKUP sẽ gửi cơ sở dữ liệu thô EXTENT (không phải trang) vào đĩa, do đó bỏ qua bước giải mã khi chúng được tải vào bộ nhớ. Tôi có thể sai, nhưng tôi đang tìm tài liệu bây giờ.
BradC

1
Đã tìm thấy nó, hãy xem huyền thoại của Paul Randal 30-09 : "Hệ thống con sao lưu mở các kênh riêng của nó vào các tệp cơ sở dữ liệu để tránh bị ảnh hưởng khi phải đọc mọi thứ vào bộ nhớ của SQL Server và sao lưu vào thiết bị sao lưu". Không đề cập cụ thể đến TDE, nhưng nếu quá trình sao lưu là kênh riêng của nó, có vẻ như thật lãng phí khi giải mã chỉ để mã hóa lại ngay lập tức. Nó thậm chí có thể xác nhận CHECKSUMS và / hoặc áp dụng nén mà không cần giải mã, nếu chúng được bật.
BradC

@BradC Tôi không nói rằng bản sao lưu sẽ hoạt động theo cách này, nhưng quá trình mã hóa / giải mã sẽ hoạt động như thế nào với dữ liệu còn lại. Nếu nó mơ hồ tôi sẽ thay đổi nó, tuy nhiên tôi không nói đây là cách sao lưu hoạt động chỉ khi và nơi mã hóa / giải mã xảy ra.
Sean Gallardy

Nhưng nếu quá trình sao lưu không sử dụng nhóm bộ đệm, thì lý do của bạn không chính xác, ngay cả khi kết luận (gói sao lưu được mã hóa) là đúng vì một lý do khác.
BradC

@BradC Không, lý do là nó đã được ghi vào đĩa nên nó đã được mã hóa ... Không chắc chắn làm thế nào bạn nhận được rằng tôi đang sao lưu một bản sao lưu được giải mã và sau đó được mã hóa lại thông qua BP. Tôi nghĩ rằng nó khá đơn giản khi nói rằng nó đã được mã hóa nên sao chép sang đĩa khác hoặc sao chép nó từ đĩa khác không giải mã được ... Không chắc bạn đang nhầm lẫn điều này như thế nào.
Sean Gallardy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.