Mysql
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Mysql

Các kết nối máy chủ MySQL của tôi có được mã hóa và an toàn không?

Một trong những yếu tố cơ bản và quan trọng nhất của quản trị dữ liệu là bảo mật. Đó là một thực tiễn tốt để triển khai bảo mật cơ sở dữ liệu bất cứ khi nào bạn có liên quan đến việc quản lý dữ liệu cho doanh nghiệp hoặc tiêu dùng hàng loạt.

Bảo mật dữ liệu là một trong những khía cạnh quan trọng nhất của việc quản trị cơ sở dữ liệu. Nó đóng một vai trò quan trọng mà mọi quản lý cơ sở dữ liệu nên thực hiện. Khi nó được triển khai và thực hiện đúng cách, kết quả sẽ không chỉ cải thiện bảo mật dữ liệu của bạn mà còn ảnh hưởng đến sự ổn định của hệ thống, nâng cao vòng đời phát triển, tăng cường tuân thủ dữ liệu của bạn và nâng cao nhận thức về bảo mật cho cấp nhóm của bạn. Mọi người đều không muốn dữ liệu của mình cuối cùng rơi vào tay kẻ xấu. Nếu dữ liệu bị vi phạm, nó không chỉ gây rủi ro cho tính bảo mật và tính toàn vẹn của dữ liệu mà còn khiến tổ chức của bạn phải đối mặt với những rủi ro tài chính đáng kể. Ngay cả khi chỉ thực hiện quản lý cơ sở dữ liệu đơn giản, nếu bạn phát hiện ra ai đó đã xâm nhập vào hệ thống của mình, cảm giác không an toàn và sợ hãi về hậu quả sẽ mang lại cho bạn là hoàn toàn không thoải mái.

Việc xác định xem kết nối máy chủ MySQL của bạn có an toàn hay không phụ thuộc vào cách MySQL truyền dữ liệu trong quá trình truyền dữ liệu an toàn như thế nào. Với kết nối không được mã hóa giữa máy khách MySQL và máy chủ, ai đó có quyền truy cập vào mạng có thể xem tất cả lưu lượng truy cập của bạn và kiểm tra dữ liệu được gửi hoặc nhận giữa máy khách và máy chủ.

Khi bạn phải di chuyển thông tin qua mạng theo cách an toàn, kết nối không được mã hóa là không thể chấp nhận được. Để làm cho bất kỳ loại dữ liệu nào không thể đọc được, hãy sử dụng mã hóa. Các thuật toán mã hóa phải bao gồm các yếu tố bảo mật để chống lại nhiều loại tấn công đã biết, chẳng hạn như thay đổi thứ tự của các thông điệp được mã hóa hoặc phát lại dữ liệu hai lần.

Nhưng MySQL của tôi an toàn, phải không?

Tin rằng MySQL của bạn an toàn mà không cần xác định tính ổn định và kiểm tra lỗ hổng bảo mật giống như một tôn giáo. Bạn có xu hướng tin ngay cả khi không nhìn thấy nó, thậm chí không cần chạm vào nó. Vấn đề là, MySQL là một công nghệ và sự tồn tại của nó không dựa trên những suy nghĩ trừu tượng. Nó phải được thử nghiệm, nó phải được chứng minh, và nó đòi hỏi sự an toàn và tuân theo các phương pháp thực hành tốt nhất đã được thử nghiệm bởi những người khác.

Việc xác định xem các kết nối máy chủ MySQL của bạn, tức là khi chuyển tiếp có an toàn hay không hoặc nó có được mã hóa hay không phụ thuộc vào "bạn đã thiết lập cơ sở dữ liệu của mình như thế nào?" hoặc "ai thiết lập cơ sở dữ liệu của bạn?".

MySQL hỗ trợ các kết nối được mã hóa giữa máy khách và máy chủ bằng giao thức TLS (Bảo mật lớp truyền tải). TLS đôi khi được gọi là SSL (Lớp cổng bảo mật) nhưng MySQL không thực sự sử dụng giao thức SSL cho các kết nối được mã hóa bởi vì mã hóa của nó yếu và SSL đã không còn được sử dụng để ủng hộ TLS. TLS sử dụng các thuật toán mã hóa để đảm bảo rằng dữ liệu nhận được qua mạng công cộng có thể được tin cậy. Nó có các cơ chế để phát hiện sự thay đổi, mất mát hoặc phát lại dữ liệu. TLS cũng kết hợp các thuật toán cung cấp xác minh danh tính bằng cách sử dụng tiêu chuẩn X.509. SSL hoặc TLS đang được sử dụng thay thế cho nhau nhưng đối với ngữ cảnh mã hóa với MySQL, TLS đang được sử dụng mà MySQL hỗ trợ các kết nối được mã hóa bằng giao thức TLSv1, TLSv1.1, TLSv1.2 và TLSv1.3.

X.509 giúp bạn có thể xác định một người nào đó trên Internet. Theo thuật ngữ cơ bản, nên có một số thực thể được gọi là “Tổ chức phát hành chứng chỉ” (hoặc CA) chỉ định chứng chỉ điện tử cho bất kỳ ai cần chúng. Chứng chỉ dựa trên các thuật toán mã hóa không đối xứng có hai khóa mã hóa (khóa công khai và khóa bí mật). Chủ sở hữu chứng chỉ có thể xuất trình chứng chỉ cho một bên khác để làm bằng chứng nhận dạng. Chứng chỉ bao gồm khóa công khai của chủ sở hữu. Mọi dữ liệu được mã hóa bằng khóa công khai này chỉ có thể được giải mã bằng khóa bí mật tương ứng do chủ sở hữu chứng chỉ nắm giữ.

Giống như người Sparta đã sử dụng Scytale

Scytale được biết đến như một cách để mã hóa và giải mã một thông điệp được sử dụng vào khoảng năm 400 trước Công nguyên. bởi người Sparta. Họ sẽ viết một thông điệp trên một tờ giấy cói (một loại giấy) được quấn quanh một cây quyền trượng. Người nhận chỉ có thể giải mã thông điệp nếu đúng đường kính và kích thước của cây trượng. Nó phục vụ như một cách để mã hóa và tránh việc trích xuất trái phép các thông điệp hoặc dữ liệu đến đích đích.

Cũng giống như với MySQL, sử dụng giao thức SSL / TLS và mật mã là một cách để tránh ai đó trích xuất dữ liệu của bạn hoặc chiếm đoạt dữ liệu của bạn khi dữ liệu được truyền qua mạng hoặc qua internet.

Theo mặc định, các chương trình MySQL cố gắng kết nối bằng cách sử dụng mã hóa nếu máy chủ hỗ trợ các kết nối được mã hóa, rơi trở lại kết nối không được mã hóa nếu không thể thiết lập kết nối được mã hóa. Kể từ phiên bản MySQL> =5.7, các tệp TLS / SSL và RSA có thể được tạo hoặc tạo với sự hỗ trợ của các biến. Đối với các bản phân phối MySQL được biên dịch bằng OpenSSL, máy chủ MySQL có khả năng tự động tạo các tệp SSL và RSA bị thiếu khi khởi động. Các biến hệ thống auto_generate_certs, sha256_password_auto_generate_rsa_keys và caching_sha2_password_auto_generate_rsa_keys (phiên bản> =8.0) kiểm soát việc tạo tự động các tệp này. Các biến này được bật theo mặc định. Chúng có thể được kích hoạt khi khởi động và kiểm tra nhưng không được đặt trong thời gian chạy.

Theo mặc định, các biến này được đặt thành BẬT hoặc bật. Nếu không, người dùng có thể gọi thủ công tiện ích mysql_ssl_rsa_setup. Đối với một số kiểu phân phối, chẳng hạn như gói RPM và DEB, lệnh gọi mysql_ssl_rsa_setup xảy ra trong quá trình khởi tạo thư mục dữ liệu. Trong trường hợp này, bản phân phối MySQL không cần phải được biên dịch bằng OpenSSL miễn là lệnh openssl có sẵn.

Khi các tệp này có sẵn và / hoặc được tạo, MySQL sẽ vẫn không sử dụng các kết nối mã hóa vì những lý do sau. Như đã đề cập trước đó, theo mặc định, các chương trình khách MySQL cố gắng thiết lập một kết nối được mã hóa nếu máy chủ hỗ trợ các kết nối được mã hóa, với khả năng kiểm soát thêm thông qua --ssl-mode (hoặc --ssl <=5.7.11 vì tính năng này đã không được dùng nữa) tùy chọn:

  • Theo mặc định, nếu kết nối MySQL không được gắn cờ với --ssl-mode, giá trị mặc định được đặt thành --ssl-mode =PREFFERED. Do đó, các máy khách cố gắng kết nối bằng cách sử dụng mã hóa, sẽ quay trở lại kết nối không được mã hóa nếu không thể thiết lập kết nối được mã hóa.

  • Với --ssl-mode =REQUIRED, máy khách yêu cầu kết nối được mã hóa và không thành công nếu không thể thiết lập được.

  • Với --ssl-mode =DISABLED, ứng dụng sử dụng kết nối không được mã hóa.

  • Với --ssl-mode =VERIFY_CA hoặc --ssl-mode =VERIFY_IDENTITY, ứng dụng khách yêu cầu kết nối được mã hóa và cũng thực hiện xác minh đối với chứng chỉ CA của máy chủ và (với VERIFY_IDENTITY) đối với tên máy chủ của máy chủ trong chứng chỉ của nó.

Với cơ chế mặc định của MySQL là sử dụng kết nối ưu tiên, có thể nó sẽ cố gắng sử dụng kết nối được mã hóa hoặc bảo mật nhưng điều này vẫn để lại một số việc cần làm và xác định.

Như đã đề cập trước đó, các biến auto_generate_certs, sha256_password_auto_generate_rsa_keys và caching_sha2_password_auto_generate_rsa_keys (version> =8.0) giúp tạo các tệp SSL / TLS và RSA cần thiết, với người dùng bình thường mà không có bất kỳ yêu cầu nào như vậy trong quá trình kết nối không an toàn. Ví dụ:hãy tạo một người dùng có tên là dbadmin.

mysql> create user 'dbadmin'@'192.168.40.%' identified by '[email protected]';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'192.168.40.%';
Query OK, 0 rows affected (0.01 sec)

Sau đó, xác minh xem các biến có được đặt chính xác hay không và sẽ được bật theo mặc định:

mysql> show global variables where variable_name in ('auto_generate_certs','sha256_password_auto_generate_rsa_keys','caching_sha2_password_auto_generate_rsa_keys');
+----------------------------------------------+-------+
| Variable_name                                | Value |
+----------------------------------------------+-------+
| auto_generate_certs                          | ON    |
| caching_sha2_password_auto_generate_rsa_keys | ON    |
| sha256_password_auto_generate_rsa_keys       | ON    |
+----------------------------------------------+-------+
3 rows in set (0.00 sec)

Xác minh xem tệp có được tạo tương ứng trong đường dẫn / var / lib / mysql / (hoặc đường dẫn của datadir cho MySQL này không):

$ find /var/lib/mysql -name "*.pem"
/var/lib/mysql/ca-key.pem
/var/lib/mysql/ca.pem
/var/lib/mysql/server-key.pem
/var/lib/mysql/server-cert.pem
/var/lib/mysql/client-key.pem
/var/lib/mysql/client-cert.pem
/var/lib/mysql/private_key.pem
/var/lib/mysql/public_key.pem

Sau đó, xác minh xem tệp SSL có được tải đúng cách hay không:

mysql> show global variables like 'ssl%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| ssl_ca        | ca.pem          |
| ssl_capath    |                 |
| ssl_cert      | server-cert.pem |
| ssl_cipher    |                 |
| ssl_crl       |                 |
| ssl_crlpath   |                 |
| ssl_fips_mode | OFF             |
| ssl_key       | server-key.pem  |
+---------------+-----------------+
8 rows in set (0.00 sec)

Xác định bảo mật cho kết nối của bạn

Bây giờ, điều này có vẻ ổn. Điều đó cũng có nghĩa là MySQL đã sẵn sàng chấp nhận các kết nối được mã hóa. Nhưng kết nối với MySQL như đã nói, nó sẽ sử dụng --ssl-mode =PREFFERED theo mặc định, hoặc nếu --ssl-mode không được chỉ định, nó sẽ vẫn dự phòng khi sử dụng kết nối không được mã hóa. Xem bên dưới:

$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;" | grep ssl -i

SSL:Không được sử dụng

Điều này cho thấy rằng nó không sử dụng kết nối an toàn. Kiểm tra các biến trạng thái phiên SSL nếu có bất kỳ mật mã nào được sử dụng hiển thị trống:

mysql> show global status like 'ssl%';
+--------------------------------+--------------------------+
| Variable_name                  | Value                    |
+--------------------------------+--------------------------+
| Ssl_accept_renegotiates        | 0                        |
| Ssl_accepts                    | 2                        |
| Ssl_callback_cache_hits        | 0                        |
| Ssl_cipher                     |                          |
| Ssl_cipher_list                |                          |
| Ssl_client_connects            | 0                        |
| Ssl_connect_renegotiates       | 0                        |
| Ssl_ctx_verify_depth           | 18446744073709551615     |
| Ssl_ctx_verify_mode            | 5                        |
| Ssl_default_timeout            | 0                        |
| Ssl_finished_accepts           | 2                        |
| Ssl_finished_connects          | 0                        |
| Ssl_server_not_after           | Aug 28 12:48:46 2031 GMT |
| Ssl_server_not_before          | Aug 30 12:48:46 2021 GMT |
| Ssl_session_cache_hits         | 0                        |
| Ssl_session_cache_misses       | 0                        |
| Ssl_session_cache_mode         | SERVER                   |
| Ssl_session_cache_overflows    | 0                        |
| Ssl_session_cache_size         | 128                      |
| Ssl_session_cache_timeouts     | 0                        |
| Ssl_sessions_reused            | 0                        |
| Ssl_used_session_cache_entries | 0                        |
| Ssl_verify_depth               | 0                        |
| Ssl_verify_mode                | 0                        |
| Ssl_version                    |                          |
+--------------------------------+--------------------------+
25 rows in set (0.002 sec)

Thực thi kết nối an toàn

Vì nó tiết lộ rằng kết nối vẫn chưa được bảo mật, MySQL giới thiệu biến Request_secure_transport yêu cầu tất cả các kết nối được thực hiện phải được mã hóa và bảo mật. Mọi nỗ lực kết nối cho một kết nối không an toàn đều không thành công. Ví dụ:bật nó trên máy chủ:

mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)

Cố gắng kết nối với tư cách khách hàng bằng kết nối không được mã hóa sẽ không thành công:

$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.

Để kết nối thành công và an toàn, bạn cần chỉ định các biến ssl-ca, ssl-cert, ssl-key. Xem bên dưới:

$ mysql [email protected] -h 192.168.40.110 -udbadmin --ssl-ca=/tmp/pem/ca.pem --ssl-cert=/tmp/pem/server-cert.pem --ssl-key=/tmp/pem/server-key.pem -e "show global status like 'ssl%'\G"
*************************** 1. row ***************************
Variable_name: Ssl_accept_renegotiates
        Value: 0
*************************** 2. row ***************************
Variable_name: Ssl_accepts
        Value: 16
*************************** 3. row ***************************
Variable_name: Ssl_callback_cache_hits
        Value: 0
*************************** 4. row ***************************
Variable_name: Ssl_cipher
        Value: TLS_AES_256_GCM_SHA384
*************************** 5. row ***************************
Variable_name: Ssl_cipher_list
        Value: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA
*************************** 6. row ***************************
Variable_name: Ssl_client_connects
        Value: 0
*************************** 7. row ***************************
Variable_name: Ssl_connect_renegotiates
        Value: 0
*************************** 8. row ***************************
Variable_name: Ssl_ctx_verify_depth
        Value: 18446744073709551615
*************************** 9. row ***************************
Variable_name: Ssl_ctx_verify_mode
        Value: 5
*************************** 10. row ***************************
Variable_name: Ssl_default_timeout
        Value: 7200
*************************** 11. row ***************************
Variable_name: Ssl_finished_accepts
        Value: 11
*************************** 12. row ***************************
Variable_name: Ssl_finished_connects
        Value: 0
*************************** 13. row ***************************
Variable_name: Ssl_server_not_after
        Value: Aug 28 12:48:46 2031 GMT
*************************** 14. row ***************************
Variable_name: Ssl_server_not_before
        Value: Aug 30 12:48:46 2021 GMT
*************************** 15. row ***************************
Variable_name: Ssl_session_cache_hits
        Value: 0
*************************** 16. row ***************************
Variable_name: Ssl_session_cache_misses
        Value: 0
*************************** 17. row ***************************
Variable_name: Ssl_session_cache_mode
        Value: SERVER
*************************** 18. row ***************************
Variable_name: Ssl_session_cache_overflows
        Value: 0
*************************** 19. row ***************************
Variable_name: Ssl_session_cache_size
        Value: 128
*************************** 20. row ***************************
Variable_name: Ssl_session_cache_timeouts
        Value: 0
*************************** 21. row ***************************
Variable_name: Ssl_sessions_reused
        Value: 0
*************************** 22. row ***************************
Variable_name: Ssl_used_session_cache_entries
        Value: 0
*************************** 23. row ***************************
Variable_name: Ssl_verify_depth
        Value: 18446744073709551615
*************************** 24. row ***************************
Variable_name: Ssl_verify_mode
        Value: 5
*************************** 25. row ***************************
Variable_name: Ssl_version
        Value: TLSv1.3

Ngoài ra, nếu người dùng được tạo bằng SSL BẮT BUỘC chẳng hạn, người dùng đó cũng sẽ kết nối với bạn bằng SSL bất kể request_secure_transport bị tắt, đây là giá trị mặc định của nó. Lưu ý rằng, nếu nhu cầu_secure_transport được bật, khả năng của nó sẽ bổ sung các yêu cầu SSL cho mỗi tài khoản, được ưu tiên hơn. Do đó, nếu một tài khoản được xác định bằng REQUIRE SSL, việc bật request_secure_transport sẽ không làm cho tài khoản đó có thể kết nối bằng tệp Unix socket.

Đảm bảo việc triển khai máy chủ MySQL được mã hóa và an toàn

Hassle-free là điều chúng tôi luôn hướng tới để không có bất kỳ vấn đề và mối quan tâm nào khác phải lo lắng. ClusterControl triển khai cơ sở dữ liệu MySQL bằng các kết nối được mã hóa và tạo chứng chỉ SSL và RSA cho bạn. Ví dụ:ảnh chụp màn hình bên dưới cho bạn thấy hoạt động công việc của lệnh Tạo cụm từ ClusterControl.

Nó thiết lập các tệp SSL và RSA và đặt chúng vào / etc / mysql / certs / path giống như bên dưới:

mysql> show global variables like 'ssl%';
+---------------+--------------------------------+
| Variable_name | Value                          |
+---------------+--------------------------------+
| ssl_ca        | /etc/mysql/certs/server_ca.crt |
| ssl_capath    |                                |
| ssl_cert      | /etc/mysql/certs/server.crt    |
| ssl_cipher    |                                |
| ssl_crl       |                                |
| ssl_crlpath   |                                |
| ssl_key       | /etc/mysql/certs/server.key    |
+---------------+--------------------------------+
7 rows in set (0.00 sec)

Sau đó, ClusterControl cũng nhóm các tệp SSL và RSA đã tạo theo kiểu tập trung trong bảng điều hướng Quản lý khóa như được hiển thị bên dưới:

Sau khi được triển khai, tất cả những gì bạn phải làm là tạo người dùng với SSL BẮT BUỘC hoặc có request_secure_transport nếu bạn muốn thực thi một lớp được mã hóa và bảo mật cho các kết nối máy chủ MySQL của mình.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL:Mã lỗi:1118 Kích thước hàng quá lớn (> 8126). Thay đổi một số cột thành TEXT hoặc BLOB

  2. Chuyển từ MySQL 5.7 sang MySQL 8.0 - Những điều bạn nên biết

  3. Sự khác biệt giữa =null và IS NULL là gì?

  4. Kiểm tra xem bảng MySQL có tồn tại mà không sử dụng cú pháp select from hay không?

  5. Hướng dẫn sử dụng MySQL - Hướng dẫn cho người mới bắt đầu học MySQL