Chia sẻ chứng chỉ được mã hóa bằng mật khẩu giữa DB và cá thể

Câu hỏi:

Tôi đang cố gắng tạo một chứng chỉ (tự ký) và triển khai trên nhiều cơ sở dữ liệu và trường hợp.

Tôi tạo và sao lưu chứng chỉ với:

USE MASTER
CREATE CERTIFICATE DavesCert ENCRYPTION BY PASSWORD ='S3creT!' WITH SUBJECT = 'The master cert'

BACKUP CERTIFICATE DavesCert TO FILE = 'd:\DavesCert.cer' 
WITH PRIVATE KEY ( DECRYPTION BY PASSWORD = 'S3creT!' ,
FILE = 'd:\DavesCert.pvk' , 
ENCRYPTION BY PASSWORD = 'S3creT!' );

Tôi khôi phục lại với

USE FOO
GO

CREATE CERTIFICATE ERecruitStatsGatheringCert       
FROM FILE = 'd:\DavesCert.cer'      
WITH PRIVATE KEY (FILE = 'd:\DavesCert.pvk', 
DECRYPTION BY PASSWORD = 'S3creT!')

và nhận được lỗi sau: "Vui lòng tạo khóa chính trong cơ sở dữ liệu hoặc mở khóa chính trong phiên trước khi thực hiện thao tác này."

Tôi không muốn tạo khóa chủ cơ sở dữ liệu. Tôi rất vui khi giải mã chứng chỉ bằng mật khẩu khi cần.

Bối cảnh: Ứng dụng SaaS. Nhiều đến nhiều mối quan hệ giữa DB và cá thể.

Tôi cần mỗi DB để có thể truy vấn các số liệu thống kê của riêng mình bằng cách thực hiện một quy trình được lưu trữ để kết thúc một số cuộc gọi đến DMV để trả về số liệu thống kê.

Ứng dụng chạy dưới một tài khoản đặc quyền thấp. Do đó, DMV yêu cầu sự cho phép XEM MÁY CHỦ NHÀ NƯỚC, do đó, tôi đang triển khai việc ký các thủ tục được lưu trữ bằng certs.

Cách cơ bản để thiết lập này là:

1. Tạo một chứng chỉ trong DB người dùng.
2. Sao lưu / khôi phục chứng chỉ đó để làm chủ.
3. Tạo đăng nhập trong master, được gán quyền đó, v.v.
4. Thêm Giấy chứng nhận vào thủ tục lưu trữ.

Tôi có mã kiểm tra cho ở trên và nó hoạt động tốt, tuy nhiên mô hình không mở rộng rất tốt để triển khai trên nhiều trường hợp / dbs.

Do đó, tôi nghĩ rằng tôi muốn sử dụng cùng một chứng chỉ trên tất cả các trường hợp / trường hợp của DB.

Hạnh phúc cho những đề xuất / cách tiếp cận khác.

--Được đăng lên Stack Exchange sau đó chuyển sang đề xuất từ ​​một mục đích sử dụng khác

Bạn chỉ xác định mật khẩu để giải mã tập tin khóa riêng với. Bạn cần thêm mật khẩu để lưu trữ chứng chỉ với:

CREATE CERTIFICATE ERecruitStatsGatheringCert        
ENCRYPTION BY PASSWORD = 'S3creT!
FROM FILE = 'd:\DavesCert.cer'       
WITH PRIVATE KEY (
    FILE = 'd:\DavesCert.pvk',  
    DECRYPTION BY PASSWORD = 'S3creT!');

Nhưng thông tin cơ bản của bạn làm cho toàn bộ bài tập vô ích. Bạn đang làm sai. Chuỗi hành động chính xác là:

1. Tạo chứng chỉ trong DB người dùng
2. Thêm chữ ký vào (các) thủ tục cửa hàng
3. Thả khóa riêng của chứng chỉ
4. Sao lưu / khôi phục chứng chỉ đó master(chỉ khóa công khai!)
5. Tạo đăng nhập master, gán quyền đó, v.v.

Lưu ý rằng không chỉ khóa riêng không bao giờ rời khỏi cơ sở dữ liệu , trên thực tế rõ ràng đã bị hủy ngay sau khi ký thủ tục. Điều này là bắt buộc để ngăn việc sử dụng thêm chứng chỉ này để ký các thủ tục khác và lạm dụng quyền đăng nhập được tạo ở bước 5. Bạn lặp lại các bước này trên mỗi cơ sở dữ liệu và sử dụng chứng chỉ khác nhau trên mỗi cơ sở dữ liệu. Bạn lặp lại các bước này mỗi lần bạn sửa đổi bất kỳ thủ tục đã ký nào và tạo chứng chỉ mới mỗi lần.

Theo nguyên tắc chung, mọi lược đồ khóa công khai / mã hóa (RSA) chữ ký / mã hóa yêu cầu một bản sao của khóa riêng đều bị hỏng. Đây là lý do tại sao được gọi là riêng tư và đây là điều mang lại giá trị cho chữ ký: kiến ​​thức chỉ tồn tại một phiên bản của khóa riêng này trên thế giới, do đó, bất cứ điều gì được ký bởi nó đều là bằng chứng cho thấy nó đến từ một và chỉ chủ sở hữu / chủ sở hữu của khóa riêng duy nhất .

Tôi biết có một số người trốn tránh khuyến nghị của tôi về việc bỏ khóa riêng ngay sau khi được sử dụng để ký thủ tục. Tôi đứng trước khuyến nghị của tôi, nhưng điều quan trọng đối với vấn đề của bạn là không bắt buộc phải sao chép khóa riêng vào[master] để tận dụng quyền ký mã mà bạn mong muốn. Bạn có thể (và nên) tạo thông tin đăng nhập được lấy từ chứng chỉ chỉ bằng khóa chung.

Về tự động hóa: Như tôi thấy, về cơ bản, nó là một công cụ (tập lệnh, ứng dụng) có hai đầu vào: bảo mật (thủ tục, chức năng, mô-đun) và quyền ( VIEW SERVER STATE). Mọi thứ khác là một quy trình tự động (tạo chứng chỉ vứt bỏ sử dụng một lần, ký, xuất chứng chỉ, nhập chứng chỉ [master], tạo đăng nhập, cấp quyền). Tên ngụ ý (tên cert, tên đăng nhập) đều có thể được tạo.

Phổ biến tên là một mối quan tâm hợp lệ. Một cách khác là chỉ sử dụng một chứng chỉ và khóa riêng được liên kết và công cụ chữ ký có thể thêm khóa riêng khi cần (khi ký thủ tục), sau đó xóa nó sau khi ký. Đây thực sự là vấn đề về cách bạn điều hành cửa hàng của mình và tầm quan trọng của tài sản bạn đang bảo vệ. Nhưng điều quan trọng là bạn không cần nhập khóa riêng vào[master] .

Tôi chưa sử dụng nhiều chứng chỉ và khóa trong sản xuất nhưng theo cách tôi hiểu khái niệm là tạo chứng chỉ bằng khóa riêng, nghĩa là sử dụng khóa chính cơ sở dữ liệu để mã hóa khóa riêng của chứng chỉ.

Tôi tìm thấy bài viết này trên Technet: http://technet.microsoft.com/en-us/l Library / bb964742.aspx

Khóa chính của cơ sở dữ liệu là một khóa đối xứng được sử dụng để bảo vệ các khóa riêng của chứng chỉ và khóa bất đối xứng có trong cơ sở dữ liệu.

Để xem liệu tôi có thể sử dụng chứng chỉ của bạn trên một máy chủ khác không, tôi đã tạo chứng chỉ của bạn mà không cần khóa riêng.

CREATE CERTIFICATE DavesCert WITH SUBJECT = 'The master cert'

Sau đó, tôi đã sao lưu nó

BACKUP CERTIFICATE DavesCert TO FILE = 'D:\MSSQL\davescert.cer'

Tôi đã chuyển chứng chỉ sang một máy chủ khác và khôi phục nó.

CREATE CERTIFICATE davescert FROM FILE = 'd:\mssql\davescert.cer'

Xem chứng chỉ

SELECT name, certificate_id, pvt_key_encryption_type_desc from sys.certificates


name    certificate_id  pvt_key_encryption_type_desc
davescert   257 NO_PRIVATE_KEY

Nếu bạn không sử dụng khóa riêng để mã hóa chứng chỉ của mình thì bạn không cần khóa chính của cơ sở dữ liệu. Nếu bạn sử dụng khóa riêng, thì bạn sẽ phải tạo khóa chính trên mỗi cơ sở dữ liệu nơi bạn sử dụng chứng chỉ của mình.

Bạn nên tạo khóa chính cho mỗi máy chủ để tránh lỗi. Đây là những gì tôi đã làm để sửa lỗi tương tự trên các máy chủ thứ cấp của mình .

drop certificate [MyCertwithPK]
drop master key 

create master key encryption by password = '4_Str0ng!MasterKey'

--verify.
open master key decryption by password = '4_Str0ng!MasterKey';
close master key;

--next.
create certifate [MyCertwithPK] from file = '\\SQL1\Backups\MyCertwithPK.cer' 
with private key (file = '\\SQL1\Backups\MyCertwithPK.key' , decryption by 
password = '4_Str0ng!CertKey') ;

--Note: My cert doesn't encrypt by password. Uses encryption hierarchy & private key instead.     

--To clarify, these were my initial create/backup cmds on my **primary** svr.
create master key encryption by password = '4_Str0ng!MasterKey';
create certificate [MyCertwithPK] with subject = 'Certificate for SQL backups with Private Key' ;
backup certificate [MyCertwithPK] to file = '\\SQL1\Backups\MyCertwithPK.cer' with private key (file= '\\SQL1\Backups\MyCertwithPK.key', encryption by password = '4_Str0ng!CertKey') ;

Kiểm tra điều này trên các máy chủ mà bạn muốn khớp cơ sở dữ liệu với khóa chính được mã hóa bằng khóa chính dịch vụ của máy chủ.

select name from sys.databases where is_master_key_encrypted_by_server=1

Tham khảo: https://docs.microsoft.com/en-us/sql/relational-database/security/encoding/sql-server-and-database-encoding-keys-database-engine

Đoạn này đã giúp tôi:

Bản sao của DMK lưu trữ trong các chủ cơ sở dữ liệu hệ thống động được cập nhật bất cứ khi nào DMK được thay đổi. Tuy nhiên, mặc định này có thể được thay đổi bằng cách sử dụng tùy chọn DROP ENCRYPTION BY SERVICE MASTER KEY của câu lệnh ALTER MASTER KEY . DMK không được mã hóa bởi khóa chính của dịch vụ phải được mở bằng cách sử dụng câu lệnh OPEN MASTER KEY và mật khẩu.