Nội dung
- Yêu cầu và Mục tiêu - Tạo cấu trúc SSL - Tạo certificate root tự ký - Tạo yêu cầu ký certificate ký tự đại diện - Tạo file cấu hình của tổ chức phát hành certificate - Ký vào Yêu cầu ký certificate để tạo certificate - Di chuyển file đến đúng vị trí - Sửa đổi các file cấu hình lãnh sự - Khởi động lại server - Kết luận

Thứ sáu, 15/08/2014 | 00:00 GMT+7

Cách bảo mật lãnh sự bằng mã hóa TLS trên Ubuntu 14.04

Consul là một công cụ khám phá dịch vụ được dùng để dễ dàng khám phá và theo dõi tình trạng của các dịch vụ khác nhau trong cơ sở hạ tầng của bạn. Bạn có thể sử dụng lãnh sự để quản lý các dịch vụ của bạn và duy trì một hệ thống kiểm tra phân tán đảm bảo rằng bạn có thể phản hồi khi các ứng dụng hoặc server gặp sự cố.

Trong hướng dẫn cuối cùng , ta tập trung vào việc cài đặt và sẵn sàng cho một môi trường sẵn sàng production . Điều này bao gồm việc tạo các file cấu hình sẽ được đọc khi khởi động và các tập lệnh khởi động để thực sự chạy các dịch vụ.

Điều này đã đưa ta đi gần hết cách để cấu hình cơ sở cuối cùng của ta , nhưng ta chưa hoàn toàn bảo mật cấu hình của bạn . Ta đã triển khai một giải pháp bí mật được chia sẻ đơn giản, rất dễ dàng mã hóa giao thức buôn chuyện của ta .

Tuy nhiên, giao tiếp RPC vẫn hoàn toàn không được mã hóa tại thời điểm này. Để giải quyết vấn đề này, lãnh sự quán hỗ trợ mã hóa TLS nguyên bản mà ta sẽ tập trung vào trong hướng dẫn này. Để thực hiện điều này, ta sẽ phải tạo một cơ quan cấp certificate và ký và phân phối khóa cho các node của ta .

Yêu cầu và Mục tiêu

Trước khi hoàn thành hướng dẫn này, bạn nên cài đặt hệ thống server lãnh sự như ta đã đề cập trong hướng dẫn cuối cùng về cài đặt cơ sở hạ tầng lãnh sự sẵn sàng production .

Các server mà ta có cho hướng dẫn đó có các thuộc tính sau:

Tên server	Địa chỉ IP	Role
server1.example.com	192.0.2.1	server lãnh sự bootstrap
server2.example.com	192.0.2.2	server lãnh sự
server3.example.com	192.0.2.3	server lãnh sự
agent1.example.com	192.0.2.50	khách hàng lãnh sự

Đây là các server Ubuntu 14.04 64-bit. Xin lưu ý mỗi server này nằm trong cùng một domain . Điều này sẽ quan trọng đối với cấu hình mà ta đang triển khai trong hướng dẫn này, vì ta sẽ tận dụng certificate ký tự đại diện sẽ trùng với bất kỳ server nào trong domain .

Trong hướng dẫn này, ta sẽ tập trung vào việc tạo tổ chức phát hành certificate TLS để ký certificate cho từng server của ta . Điều này sẽ cho phép các thành phần lãnh sự xác minh danh tính và mã hóa lưu lượng truy cập. Sau đó, ta sẽ sửa đổi các file cấu hình một chút để buộc các node của ta mã hóa lưu lượng.

Tạo cấu trúc SSL

Để bắt đầu, ta sẽ cài đặt một số file và folder cơ bản mà ta sẽ sử dụng để quản lý khóa của bạn .

, ta sẽ thực hiện tất cả các quy trình trong hướng dẫn này từ bên trong shell root . Đăng nhập bằng quyền root hoặc sử dụng sudo -i với quyền user có quyền sudo.

Trên mỗi thành viên lãnh sự của bạn, hãy tạo một folder ssl bên trong folder /etc/consul.d . Đây là nơi ta sẽ giữ các file cần thiết để mã hóa lưu lượng RPC:

mkdir /etc/consul.d/ssl

Trên server mà bạn định sử dụng làm tổ chức phát hành certificate của bạn , ta sẽ tạo một folder con trong folder này để chứa tất cả các file cần thiết để tạo và ký certificate . Ta có thể chọn bất kỳ server nào của bạn để chứa tổ chức phát hành certificate , nhưng vì mục đích của ta , ta sẽ sử dụng máy server1 cũng chứa cấu hình bootstrap.

Trên server này, hãy tạo một folder con có tên là CA trong folder ta vừa tạo:

mkdir /etc/consul.d/ssl/CA

Điều này sẽ chứa một số dữ liệu nhạy cảm mà ta có thể không muốn người khác truy cập, vì vậy hãy khóa quyền:

chmod 0700 /etc/consul.d/ssl/CA

Di chuyển vào folder này trên server CA.

cd /etc/consul.d/ssl/CA

Ở đây, ta sẽ tạo một số file cơ bản cần có cho việc ký certificate của ta . Đầu tiên, ta cần tạo một file sẽ được tăng dần với số sê-ri có sẵn tiếp theo cho các certificate . Ta cần gieo trước giá trị này.

Để thực hiện việc này, hãy lặp lại giá trị 000a vào file nối tiếp:

echo "000a" > serial

Ta cũng cần cung cấp một file mà cơ quan cấp certificate của ta có thể ghi lại các certificate mà tổ chức đó ký. Ta sẽ gọi file này là certindex :

touch certindex

Tạo certificate root tự ký

Để bắt đầu với tổ chức phát hành certificate của ta , bước đầu tiên ta cần làm là tạo certificate root tự ký. Ta có thể làm điều đó với lệnh openssl được cài đặt mặc định trên máy Ubuntu.

Lệnh mà ta sẽ sử dụng để tạo certificate là:

openssl req -x509 -newkey rsa:2048 -days 3650 -nodes -out ca.cert

Hãy xem điều này nghĩa là gì:

req : Đối số này cho openssl biết rằng bạn quan tâm đến việc vận hành trên certificate PKCS # 10 , bằng cách tạo hoặc xử lý các yêu cầu.
-x509 : Đối số này chỉ định rằng bạn muốn certificate tự ký thay vì certificate request . Điều này thường được thực hiện đối với certificate CA root .
-newkey rsa: 2048 : Điều này yêu cầu openssl tạo certificate request mới và private key . Ta chuyển cho nó một đối số xác định rằng ta muốn một khóa RSA 2048 bit.
-days 3650 : Ở đây, ta chỉ định số ngày mà certificate được coi là hợp lệ. Ta đang sử dụng giá trị 3650 , tức là 10 năm.
-nodes : Điều này chỉ định rằng private key được tạo sẽ không được mã hóa bằng DES, khóa này sẽ yêu cầu password . Điều này tránh được yêu cầu đó.
-out ca.cert : Điều này đặt tên file sẽ được sử dụng cho file certificate đã tạo.

Trong quá trình tạo certificate , bạn sẽ được yêu cầu nhập thông tin về server mà bạn đang chứng nhận. Bạn có thể điền vào điều này với bất kỳ thông tin liên quan nào bạn muốn về server :

. . . Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:ConsulCA Email Address []:admin@example.com

Đối với Common Name , sẽ quan trọng trong certificate khác của ta , bạn có thể đặt bạn muốn .

Khi hoàn tất, bạn sẽ có một file certificate ca.cert , cũng như một khóa liên quan được gọi là privkey.pem .

Tạo yêu cầu ký certificate ký tự đại diện

Bây giờ ta đã có certificate CA root , ta có thể tạo yêu cầu ký certificate cho các client của bạn .

Trong trường hợp này, tất cả các thành viên lãnh sự của ta đều là khách hàng, bao gồm cả server mà ta đang vận hành. Thay vì tạo một certificate duy nhất cho từng server và ký nó với CA của ta , ta sẽ tạo một certificate ký tự đại diện sẽ hợp lệ cho bất kỳ server nào trong domain của ta .

Định dạng chung của lệnh sẽ giống nhau, với một số khác biệt nhỏ:

openssl req -newkey rsa:1024 -nodes -out consul.csr -keyout consul.key

Sự khác biệt giữa certificate request CA root tự ký mà ta đã tạo và yêu cầu ký certificate mới mà ta đang tạo hiện ở đây:

no -x509 flag : Ta đã xóa cờ -x509 để tạo yêu cầu ký certificate thay vì certificate tự ký.
-out consul.csr : Bản thân file được xuất ra không phải là certificate mà là một yêu cầu ký certificate .
-keyout consul.key : Ta đã chỉ định tên của khóa được liên kết với yêu cầu ký certificate .

, ta sẽ được yêu cầu trả lời cho yêu cầu ký certificate (CSR). Điều này quan trọng hơn câu trả lời mà ta đã cung cấp cho certificate CA root tự ký. Tại đây, ta cần sử dụng Common Name dùng ký tự đại diện để certificate của ta được xác nhận là hợp lệ cho mỗi server của ta :

. . . Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:*.example.com Email Address []:admin@example.com  Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

Như bạn thấy ở đây, ta đã sử dụng domain của bạn , với dấu hoa thị làm server lưu trữ để biểu thị rằng certificate phải được coi là hợp lệ cho bất kỳ server nào trong domain . Bạn có thể bỏ qua password thử thách một cách an toàn và dấu nhắc tên công ty tùy chọn được thêm vào cuối.

Tạo file cấu hình của tổ chức phát hành certificate

Bây giờ, ta có file certificate CA root tự ký và yêu cầu ký certificate ký tự đại diện trùng với tất cả các server trong domain của ta . Trước khi ta có thể ký yêu cầu ký bằng certificate CA của bạn , ta cần tạo một file cấu hình sẽ kiểm soát cách điều này xảy ra.

Ta sẽ gọi file mà ta đang tạo myca.conf sẽ chứa thông tin CA của ta . Mở file này ngay bây giờ:

nano /etc/consul.d/ssl/CA/myca.conf

Tệp này sử dụng định dạng INI được chia thành nhiều phần. Phần đầu tiên ta sẽ xác định là phần ca Điều duy nhất ta sẽ làm ở đây là trỏ đến phần do user xác định của ta với thông tin CA thực tế:

[ ca ] default_ca = myca

Tiếp theo, ta sẽ tạo phần mà ta vừa tham chiếu. Điều này sẽ chứa phần lớn các chi tiết cấu hình CA.

Ta sẽ chỉ định rằng thông tin được nhập vào dấu nhắc certificate không nhất thiết phải là duy nhất. Sau đó, ta sẽ cung cấp vị trí của tất cả các file mà ta đã tạo cần cho quá trình ký. Ta sẽ yêu cầu openssl đặt các certificate mới trong folder hiện tại.

Ta cũng muốn chọn một số mặc định được sử dụng khi không có lựa chọn thay thế nào được chỉ định trên dòng lệnh. Ta sẽ chọn các certificate đã ký là tốt trong 10 năm và sẽ sử dụng thuật toán sha1 . Cuối cùng, ta sẽ chỉ ra một số phần bổ sung mà ta sẽ tạo để xác định thông tin bổ sung:

[ myca ] unique_subject = no new_certs_dir = . certificate = ca.cert database = certindex private_key = privkey.pem serial = serial default_days = 3650 default_md = sha1 policy = myca_policy x509_extensions = myca_extensions

Bây giờ, hãy tập trung vào phần đầu tiên do user xác định mà ta vừa tham chiếu, phần này được sử dụng để quyết định thông tin nào cần được cung cấp để CSR được chấp nhận. Ta sẽ đánh dấu một số trường là bắt buộc và những trường khác là tùy chọn. Ta sẽ đưa ra một số lựa chọn khá chuẩn cho các dấu nhắc thông thường:

[ myca_policy ] commonName = supplied stateOrProvinceName = supplied countryName = supplied emailAddress = optional organizationName = supplied organizationalUnitName = optional

Phần cuối cùng sẽ xác định các phần mở rộng x509 mà ta muốn sử dụng khi ký certificate .

Trước tiên, ta cần nói với nó rằng certificate mà ta sẽ ký không phải là certificate CA. Ta sẽ sử dụng giá trị chuẩn của "băm" cho mã định danh khóa chủ đề vì chuỗi hex (thay thế) không được khuyến khích.

Ta sẽ đặt số nhận dạng khóa ủy quyền thành “keyid” để sao chép số nhận dạng khóa chủ đề từ certificate chính. Ta cũng sẽ chỉ định rằng các khóa được dùng làm chữ ký hoặc với một giao thức mã hóa khóa. Ta sẽ chỉ định rằng việc sử dụng mở rộng các khóa có thể dành cho xác thực server và client :

[ myca_extensions ] basicConstraints = CA:false subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always keyUsage = digitalSignature,keyEncipherment extendedKeyUsage = serverAuth,clientAuth

Tất cả cùng nhau, file trông giống như sau:

[ ca ] default_ca = myca  [ myca ] unique_subject = no new_certs_dir = . certificate = ca.cert database = certindex private_key = privkey.pem serial = serial default_days = 3650 default_md = sha1 policy = myca_policy x509_extensions = myca_extensions  [ myca_policy ] commonName = supplied stateOrProvinceName = supplied countryName = supplied emailAddress = optional organizationName = supplied organizationalUnitName = optional  [ myca_extensions ] basicConstraints = CA:false subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always keyUsage = digitalSignature,keyEncipherment extendedKeyUsage = serverAuth,clientAuth

Lưu file khi bạn hoàn tất. Bây giờ ta có một file cấu hình quan trọng được dùng để ký yêu cầu ký certificate mà ta đã tạo trước đó.

Ký vào Yêu cầu ký certificate để tạo certificate

Bây giờ, ta có tất cả các thành phần cần thiết để ký CSR và tạo certificate . Ta chỉ cần tham chiếu file cấu hình mà ta vừa tạo và chuyển vào CSR ta đã tạo.

Lệnh ta sẽ sử dụng là:

openssl ca -batch -config myca.conf -notext -in consul.csr -out consul.cert

Các tùy chọn ta sử dụng là:

ca : Sử dụng chức năng quản lý tổ chức phát hành certificate của openssl.
-batch : Chỉ định rằng nó sẽ vào chế độ hàng loạt. Chế độ hàng loạt tự động xác nhận bất kỳ CSR nào được chuyển vào mà không cần nhắc nhở.
-config myca.conf : Truyền vào file cấu hình mà ta đã tạo.
-notext : Không xuất ra dạng văn bản của certificate .

Phần còn lại của các tùy chọn chỉ định các file đầu vào và kết quả .

Thao tác này sẽ tạo ra một file có tên consul.cert trong folder hiện tại. Nó cũng sẽ tạo các version mới của các file serial và certindex , chuyển các version cũ sang các file backup . Tệp .pem cũng sẽ được tạo dựa trên số sê-ri trong file serial .

Di chuyển file đến đúng vị trí

Bây giờ, ta có tất cả các thành phần mà ta cần trong folder /etc/consul.d/ssl/CA . Ta muốn sao chép ba file ta cần vào folder /etc/consul.d/ssl , nơi ta sẽ tham chiếu chúng:

cp ca.cert consul.key consul.cert ..

Máy server1 của ta chứa CA hiện có certificate cần thiết và các file khóa ở đúng vị trí.

Để đưa chúng vào các máy khác trong cơ sở hạ tầng của bạn, scp là một lựa chọn tốt. Từ folder /etc/consul.d/ssl trên server1 , bạn có thể đẩy các file cần thiết sang các server khác bằng lệnh :

cd /etc/consul.d/ssl scp ca.cert consul.key consul.cert root@192.0.2.2:/etc/consul.d/ssl scp ca.cert consul.key consul.cert root@192.0.2.3:/etc/consul.d/ssl scp ca.cert consul.key consul.cert root@192.0.2.50:/etc/consul.d/ssl

Thay đổi địa chỉ IP để tham chiếu đến từng máy trong cơ sở hạ tầng của bạn.

Sửa đổi các file cấu hình lãnh sự

Như vậy, ta đã có file certificate root và cặp certificate / khóa cho các thành viên lãnh sự, ta có thể sửa đổi file cấu hình lãnh sự của bạn để tham chiếu đến các file này.

Mở từng file cấu hình lãnh sự trên server của bạn. Đối với máy server1 của ta , ta sẽ bắt đầu với file cấu hình bootstrap:

nano /etc/consul.d/bootstrap/config.json

Tệp hiện tại sẽ trông như thế này:

{     "bootstrap": true,     "server": true,     "datacenter": "nyc2",     "data_dir": "/var/consul",     "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",     "log_level": "INFO",     "enable_syslog": true }

Điều đầu tiên ta nên làm là sử dụng các thông số lãnh sự để xác định từng profile mới của ta . Tham số ca_file tham chiếu đến vị trí của file certificate CA. Các cert_file và key_file thông số tham khảo certificate và khóa các file của khách hàng tương ứng.

Vì những điều này cũng liên quan đến mã hóa, ta sẽ thêm nó vào bên dưới tham số encrypt để rõ ràng:

{     "bootstrap": true,     "server": true,     "datacenter": "nyc2",     "data_dir": "/var/consul",     "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",     "ca_file": "/etc/consul.d/ssl/ca.cert",     "cert_file": "/etc/consul.d/ssl/consul.cert",     "key_file": "/etc/consul.d/ssl/consul.key",     "log_level": "INFO",     "enable_syslog": true }

Bây giờ, ta đã xác định vị trí của các file này, nhưng ta chưa nói với lãnh sự rằng ta muốn xác minh tính xác thực của từng server sử dụng các file này. Ta có thể làm điều đó ngay bây giờ bằng cách yêu cầu lãnh sự xác minh cả kết nối đến và đi:

{     "bootstrap": true,     "server": true,     "datacenter": "nyc2",     "data_dir": "/var/consul",     "encrypt": "pmsKacTdVOb4x8/Vtr9PWw==",     "ca_file": "/etc/consul.d/ssl/ca.cert",     "cert_file": "/etc/consul.d/ssl/consul.cert",     "key_file": "/etc/consul.d/ssl/consul.key",     "verify_incoming": true,     "verify_outgoing": true,     "log_level": "INFO",     "enable_syslog": true }

Lưu file khi bạn hoàn tất.

Thực hiện những thay đổi tương tự đối với từng file cấu hình mà các thành viên lãnh sự của bạn sử dụng.

Trên server1 , bạn cần thực hiện những thay đổi này đối với /etc/consul.d/bootstrap/config.json và /etc/consul.d/server/config.json .

Trên các server khác, bạn chỉ cần sửa đổi /etc/consul.d/server/config.json . Trên (các) client của bạn, bạn sẽ phải sửa đổi /etc/consul.d/client/config.json .

Khởi động lại server

Để thực hiện truy cập được mã hóa của ta , bạn phải bắt đầu lại phiên lãnh sự lần lượt trên từng thành viên lãnh sự của bạn.

Trên mỗi máy trong cơ sở hạ tầng của bạn, hãy dừng lại nhanh chóng và sau đó bắt đầu lại lãnh sự:

stop consul && sleep 5 && start consul

Thao tác này sẽ dừng quá trình và khởi động lại trong giây lát.

Nếu bạn làm điều này lần lượt với từng thành viên lãnh sự của bạn , họ sẽ chuyển sang sử dụng SSL để mã hóa lưu lượng RPC giữa họ. Khi chỉ một số trong số chúng được chuyển sang, một số vấn đề giao tiếp có thể tồn tại trong thời gian ngắn do một số lưu lượng bị từ chối do không được mã hóa.

Khi tất cả các thành viên được khởi động lại, lưu lượng RPC phải được mã hóa hoàn toàn.

Kết luận

Đến đây, bạn nên có một hệ thống khám phá dịch vụ khá an toàn cho cơ sở hạ tầng của bạn . Ta đã tận dụng tất cả các hệ thống an ninh bản địa có sẵn với lãnh sự để khóa quyền truy cập và ngăn chặn việc giả mạo các máy khác nhau của ta .

Tags:

Các tin liên quan