Ngày nay, bảo mật là điều tối quan trọng trong toàn bộ lĩnh vực CNTT. Đôi khi, chúng ta nghe nói về các cuộc tấn công ransomware hoặc rò rỉ dữ liệu có nguồn gốc từ cơ sở dữ liệu hoặc cơ sở hạ tầng CNTT không được bảo mật. Bạn có thể tự hỏi:đâu là phương pháp hay nhất trong việc kiến trúc môi trường MySQL để bạn có thể an tâm về dữ liệu của mình? Nếu vậy, blog này là dành cho bạn. Xin lưu ý rằng chúng tôi sẽ không trình bày đầy đủ về chủ đề - điều này sẽ phù hợp với sách trắng hơn là blog. Chúng tôi sẽ cố gắng hết sức để đề cập đến các khía cạnh quan trọng nhất của việc bảo mật cơ sở dữ liệu MySQL của bạn. Ý tưởng đằng sau blog này là để người đọc biết những gì họ không biết và giúp xác định các chủ đề và từ khóa để nghiên cứu thêm. Chúng tôi sẽ minh họa điều đó bằng ảnh chụp màn hình từ sản phẩm của chúng tôi, ClusterControl, đi kèm với một loạt các tính năng, bao gồm một số tính năng xung quanh bảo mật cơ sở dữ liệu.
Mạng
Trước hết, chúng ta phải triển khai MySQL ở đâu đó. Có thể là phiên bản độc lập, bản sao không đồng bộ chính - bản sao hoặc một trong các cấu trúc liên kết nhân bản đồng bộ, nâng cao hơn như Galera hoặc InnoDB Cluster. Bất kể nó là gì, nó phải được bảo vệ ở cấp độ mạng. Cơ sở dữ liệu chứa dữ liệu, khá phổ biến, là tài sản quý giá nhất của cả một tổ chức.
Bảo mật quyền truy cập
Các trường hợp cơ sở dữ liệu không bao giờ được đặt trên mạng công cộng. Các phân đoạn mạng trong đó cơ sở dữ liệu được định cấu hình chỉ có thể truy cập được từ một số lượng hạn chế của các mạng khác. Quy tắc chung là - một nút nhất định có thể truy cập vào mạng cơ sở dữ liệu không? Nếu câu trả lời là không, các mạng nên được tách biệt.
Tất nhiên, tất cả phụ thuộc vào thiết lập chính xác nhưng trong các trường hợp phổ biến nhất, khi bạn có các lớp ứng dụng, proxy, bộ nhớ cache và cơ sở dữ liệu, thiết lập điển hình nhất sẽ là chỉ proxy mới có thể để truy cập cơ sở dữ liệu. Tất cả các thực thể khác phải được cấu hình theo cách mà chúng chỉ truy cập vào cơ sở dữ liệu thông qua lớp proxy. Thiết kế này tốt về nhiều mặt. Ngoài việc tăng cường bảo mật, nó cũng giúp che giấu sự phức tạp của tầng cơ sở dữ liệu khỏi ứng dụng.
Lớp proxy phải tuân theo cấu trúc liên kết cơ sở dữ liệu và phải xử lý các lỗi nút cơ sở dữ liệu và các thay đổi cấu trúc liên kết. Ứng dụng, kết nối với lớp proxy, phải luôn có thể tiếp cận với nút cơ sở dữ liệu đang hoạt động có liên quan đến loại yêu cầu. Tương tự với lớp bộ nhớ cache. Nó có thể được triển khai trong lớp proxy, một số proxy như ProxySQL cho phép các yêu cầu bộ nhớ cache bên trong proxy nhưng nếu nó là một lớp riêng biệt được xây dựng xung quanh, chẳng hạn như memcache hoặc Redis, thì nó phải luôn tiếp cận cơ sở dữ liệu thông qua lớp proxy.
Một loại nút nữa có thể cần để có quyền truy cập trực tiếp vào lớp cơ sở dữ liệu là các nút quản lý - những nút được các nhóm vận hành sử dụng để quản lý cơ sở dữ liệu. Lý do rất đơn giản:một số nhiệm vụ bảo trì có thể yêu cầu quyền truy cập trực tiếp vào cơ sở dữ liệu. Đó có thể là các tập lệnh tự động hóa tác vụ, cuốn sách phát Ansible trên toàn bộ nhóm cơ sở dữ liệu hoặc các tác vụ khác. Trong trường hợp đó, rõ ràng, các biện pháp bảo mật cần được áp dụng để đảm bảo rằng chỉ những người có quyền truy cập mới có thể đăng nhập vào nút quản lý đó.
Một loại nút khả thi khác (mặc dù các nút quản lý cũng có thể được sử dụng cho việc đó) có thể yêu cầu quyền truy cập vào cơ sở dữ liệu là các nút liên quan đến việc thu thập số liệu và hiển thị chúng cho người dùng - chúng ta đang nói ở đây về việc giám sát và các hoạt động cảnh báo.
VPN
Đối với bất kỳ loại tầng cơ sở dữ liệu nào trải dài trên nhiều trung tâm dữ liệu, bạn nên cân nhắc sử dụng VPN để kết nối chúng. Kết nối mở, không mã hóa qua mạng WAN là điều không bao giờ nên xảy ra. Ngay cả việc thiết lập mã hóa SSL không phải là lựa chọn tốt nhất vì nó sẽ yêu cầu mở quyền truy cập giữa tầng cơ sở dữ liệu và mạng WAN - Kết nối SSL giữa các nút cơ sở dữ liệu yêu cầu chúng có thể kết nối trực tiếp. VPN giải quyết vấn đề này bằng cách thêm người trung gian tạo ra một cách an toàn để kết nối các phân đoạn của mạng tầng cơ sở dữ liệu.
VPN cũng phải là bắt buộc đối với bất kỳ loại truy cập nào của người dùng vào mạng của tổ chức vì nó triển khai kết nối an toàn giữa máy trạm và mạng sản xuất.
Tường lửa
Tất nhiên, trong khi bảo mật mạng, chúng ta nên cân nhắc sử dụng tường lửa. Nói chung, mọi nút cơ sở dữ liệu chỉ nên nhận các kết nối từ một nhóm nguồn xác định - tên máy chủ và cổng. Ngay cả các phân đoạn mạng “bắt buộc” cũng không được có toàn quyền truy cập vào mạng cơ sở dữ liệu mà chỉ đến các cổng được yêu cầu. Nếu proxy chỉ cần kết nối với cổng cơ sở dữ liệu, thì không có lý do gì để nó có thể truy cập bất kỳ cổng nào khác trên các nút cơ sở dữ liệu. Cũng xin lưu ý rằng bạn không nên sử dụng các cổng mặc định. Rõ ràng là bảo mật bằng cách che giấu - sau khi tất cả các cổng được mở ở đâu đó, nhưng nó giúp đối phó với ít nhất một số xâm nhập bảo mật sử dụng các tập lệnh tự động. Nó sẽ không ngăn cản ai đó quyết tâm có được quyền truy cập nhưng có thể làm chậm anh ta (khi kết hợp với các biện pháp phát hiện quét cổng và chống quét) đồng thời ngăn các cuộc tấn công tự động thành công.
Bảo mật Cơ sở dữ liệu
Mạng là tuyến phòng thủ đầu tiên, bạn có thể sử dụng các biện pháp bảo mật và thực tiễn tốt khác để cải thiện bảo mật của mình hơn nữa. Một số trong số chúng có thể được triển khai trên chính cơ sở dữ liệu.
Người dùng và máy chủ lưu trữ
Bản thân các cơ sở dữ liệu có thể được sử dụng để triển khai các hạn chế và kiểm soát truy cập. Đối với người mới bắt đầu, bạn có thể triển khai kiểm soát truy cập dựa trên máy chủ lưu trữ, ngăn các máy chủ khác ngoài danh sách ngắn các nút đăng nhập vào cơ sở dữ liệu. Tất nhiên, nếu bạn đã sử dụng tường lửa để giới hạn quyền truy cập, điều này nghe có vẻ giống như trùng lặp nhưng bạn vẫn nên hạn chế quyền truy cập trên chính cơ sở dữ liệu - bạn không bao giờ biết khi nào, một cách ngẫu nhiên, tường lửa sẽ bị vô hiệu hóa. Trong trường hợp này, bạn vẫn có lớp bảo vệ thứ hai.
Những gì bạn muốn triển khai ở đây là danh sách người dùng cơ sở dữ liệu và máy chủ được phép truy cập cơ sở dữ liệu. Nhiều khả năng những gì bạn sẽ gặp phải là một hoặc nhiều người dùng được cấp quyền truy cập từ các máy chủ nằm trong lớp proxy. Bạn có thể có kiểm soát truy cập chi tiết như thế nào tùy thuộc vào hệ thống cơ sở dữ liệu mà bạn có. Ví dụ:MySQL không cho phép kiểm soát chi tiết các mặt nạ mạng - nó chỉ sử dụng / 32, / 24, / 16 hoặc / 8. Mặt khác, trong PostgreSQL, bạn có thể sử dụng bất kỳ loại mặt nạ mạng nào.
Tài trợ
Nếu đây là những gì cơ sở dữ liệu của bạn cho phép, thì mỗi người dùng phải có một tập hợp các khoản trợ cấp được xác định - đảm bảo rằng các đặc quyền được chỉ định cho họ là mức tối thiểu cần thiết để người dùng thực hiện các hành động mà anh ta phải làm . Các hệ thống cơ sở dữ liệu có thể có các tập hợp đặc quyền khác nhau và các cấp độ khác nhau của chúng. Thông thường, chúng tôi có một số cấp đặc quyền - toàn cầu, ảnh hưởng đến toàn bộ máy chủ cơ sở dữ liệu, cấp lược đồ - người dùng được cung cấp có thể có các đặc quyền khác nhau được gán cho các lược đồ khác nhau. Bạn có thể có đặc quyền ở cấp bảng hoặc thậm chí cột. Như chúng tôi đã đề cập trước đây, mục tiêu là tạo ra nhóm đặc quyền tối thiểu cho mọi người dùng. Bạn có thể sẽ muốn có ít nhất một người dùng có đặc quyền cao - nó sẽ được sử dụng để quản lý cơ sở dữ liệu. Người dùng như vậy nên được giới hạn nghiêm ngặt khi nói đến kết nối. Nó không được phép (và trên thực tế là cả người dùng đều không) được phép kết nối từ bất kỳ vị trí nào - nó phải là một localhost hoặc một số nút quản lý cụ thể, dành riêng để thực hiện các hoạt động trên cơ sở dữ liệu.
Quản lý mật khẩu
Mọi người dùng trong cơ sở dữ liệu phải có mật khẩu được xác định. Đây là không có trí tuệ. Mật khẩu nên được lưu trữ ở dạng băm. Bạn nên đảm bảo rằng để lưu trữ các mật khẩu, bạn đang sử dụng thuật toán băm an toàn nhất mà cơ sở dữ liệu của bạn phải cung cấp. Mật khẩu không được dễ đoán và cũng không được dễ bị tấn công từ điển. Một số hệ thống cơ sở dữ liệu, như MySQL, cho phép bạn xác định chính xác các yêu cầu mà mật khẩu của bạn phải đáp ứng để chúng được sử dụng. Chữ thường và chữ hoa, số, ký tự đặc biệt, độ dài của mật khẩu - tất cả đều quan trọng và nếu bạn có thể thực thi một số chính sách về độ mạnh của mật khẩu, bạn nên làm điều đó. Một bit quan trọng khác là xoay mật khẩu. Mật khẩu không nên được tạo một lần và trong suốt thời gian tồn tại của cơ sở dữ liệu, bạn nên có chính sách xoay vòng mật khẩu. Một lần nữa, một số hệ thống cơ sở dữ liệu có thể thực thi điều này cho bạn. Người dùng quản trị có thể tạo tài khoản người dùng mới với việc xoay vòng mật khẩu được thực thi. Anh ta cũng có thể thực thi xoay vòng mật khẩu cho một người dùng nhất định.
Nhật ký kiểm tra
Một số hệ thống cơ sở dữ liệu cung cấp nhật ký kiểm tra - ý tưởng là thu thập càng nhiều thông tin về hoạt động trong cơ sở dữ liệu càng tốt. Ai và đã làm gì khi nào? Truy vấn nào đã được thực hiện, bởi ai? Ai đã cố gắng đăng nhập nhưng không thành công? Từ máy chủ nào? Lý tưởng nhất là các bản ghi chứa thông tin như vậy sẽ được lưu trữ bên ngoài các nút cơ sở dữ liệu. Bạn có thể truyền chúng đến máy chủ nhật ký trung tâm của mình để bảo quản an toàn, xử lý thêm và khả năng tìm kiếm tốt hơn.
Bảo mật SQL
Chúng tôi đã đề cập đến người dùng và máy chủ lưu trữ nhưng cuộc tấn công cũng có thể xảy ra từ một nguồn khác. Nếu ứng dụng của bạn không được bảo mật đúng cách và đầu vào không được xác thực chính xác, bạn có thể đang phải đối mặt với các cuộc tấn công bắt nguồn từ trang web của mình. Chúng ta đang nói ở đây về SQL injection. Trong trường hợp như vậy, tường lửa không thực sự hữu ích vì truy vấn bắt nguồn từ một nguồn hợp lệ (máy chủ web của bạn và sau đó là nút proxy). Việc chỉ định các khoản tài trợ thực sự có thể giúp ngăn chặn một số kiểu tấn công này, nhưng nó không phải là một giải pháp lý tưởng - sau tất cả, ứng dụng của bạn, trong phần lớn các trường hợp, sẽ cần một người dùng có thể xóa hoặc sửa đổi nội dung của cơ sở dữ liệu. Người dùng như vậy, khi bị lợi dụng, có thể bị lợi dụng để gây hại. Có một số cách mà bạn có thể thử để đối phó với việc điều trị.
Tường lửa SQL
Cách đơn giản nhất để thực hiện là cài đặt tường lửa SQL. Nó có thể được thực hiện ở các cấp độ khác nhau và ở những nơi khác nhau. Một trong những lựa chọn là sử dụng bộ cân bằng tải cho việc đó. Một số trong số chúng đi kèm với chức năng này, ít nhất có thể dễ dàng đạt được nếu chưa được triển khai. Ý tưởng đằng sau nó là xây dựng một danh sách các truy vấn mà ứng dụng của bạn thực thi và sau đó định cấu hình proxy của bạn để chỉ chuyển qua loại lưu lượng này. Nó không phải là lý tưởng vì bạn sẽ phải duy trì nó kịp thời, thêm các truy vấn mới và loại bỏ các truy vấn cũ không được sử dụng nữa. Mặt khác, một bộ quy tắc như vậy sẽ ngăn bất kỳ truy vấn nào không được phép truy cập vào cơ sở dữ liệu.
Phát hiện chèn SQL
Một tùy chọn khả thi khác là triển khai phát hiện chèn SQL trong lớp proxy. Có một số giải pháp, ProxySQL trong số những giải pháp khác, có thể được định cấu hình để cố gắng phát hiện việc đưa vào SQL trong lưu lượng đang đi qua chúng. Tất nhiên, tất cả đều dựa trên heuristics nên có thể dẫn đến kết quả dương tính giả, nhưng nó có thể là một bổ sung tốt cho tường lửa SQL.
Trước đây, chúng ta đã thảo luận về cách bạn có thể triển khai tường lửa SQL và phát hiện chèn SQL bằng ProxySQL, một trình cân bằng tải có thể được triển khai từ ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Bảo mật Dữ liệu
Cuối cùng là bảo mật dữ liệu. Chúng tôi đã thảo luận cho đến nay cách người ta có thể làm cứng cơ sở dữ liệu, cách giới hạn quyền truy cập vào nó và cách ngăn chặn các loại tấn công khác nhau đến từ chính ứng dụng. Chúng ta vẫn nên xem xét việc bảo vệ dữ liệu của chính nó. Điều này có thể có nhiều lớp. Bảo mật vật lý - nếu bạn sở hữu trung tâm dữ liệu, hãy đảm bảo nó được khóa đúng cách. Nếu bạn sử dụng các nhà cung cấp dịch vụ đám mây hoặc ISP bên ngoài, hãy đảm bảo họ có các giao thức bảo mật phù hợp khi truy cập phần cứng. Sau đó, chúng tôi có một máy chủ, máy ảo hoặc bất kỳ cách nào bạn đang sử dụng. Dữ liệu nằm trên đĩa, được lưu trữ cục bộ trên máy chủ. Dữ liệu đang được chuyển giữa ứng dụng, proxy và cơ sở dữ liệu. Dữ liệu được chuyển giữa các nút cơ sở dữ liệu bằng phương tiện sao chép. Dữ liệu đang được lưu trữ bên ngoài dưới dạng bản sao lưu. Dữ liệu này cần được bảo vệ.
Bản sao lưu
Các bản sao lưu phải luôn được mã hóa. Khóa mã hóa phải được bảo quản cẩn thận và được luân chuyển thường xuyên.
Dữ liệu đang chuyển
Dữ liệu được truyền phải được mã hóa. Đảm bảo rằng bạn đã định cấu hình ứng dụng, lớp proxy và cơ sở dữ liệu của mình để sử dụng SSL hoặc TSL. Mọi phương tiện truyền dữ liệu giữa các nút cơ sở dữ liệu cũng phải được bảo mật và mã hóa. Mục đích là làm cho bất kỳ loại dò tìm mạng nào trở nên vô nghĩa.
Dữ liệu ở trạng thái nghỉ
Cuối cùng, chính dữ liệu, được lưu trữ trên nút cơ sở dữ liệu. Nó cũng nên được mã hóa. Có một số phương pháp bạn có thể sử dụng khi tiếp cận chủ đề này. Đầu tiên, mã hóa ở cấp độ máy chủ. Ổ đĩa mà cơ sở dữ liệu có thư mục dữ liệu của nó có thể được mã hóa (và giải mã khi khởi động). Cơ sở dữ liệu cũng có xu hướng đi kèm với khả năng mã hóa. Những gì có thể được mã hóa phụ thuộc vào giải pháp chính xác và loại và phiên bản của cơ sở dữ liệu, nhưng trong một số trường hợp, các tùy chọn khá rộng rãi. Mã hóa vùng bảng, mã hóa nhật ký, đôi khi thậm chí mã hóa cấu trúc trong bộ nhớ. Nếu bạn làm đúng cách, việc truy cập vào nút cơ sở dữ liệu sẽ không đủ để truy cập dữ liệu.
Kết luận
Như chúng tôi đã đề cập trước đây, blog này không nhằm mục đích hướng dẫn thực hành về bảo mật cơ sở dữ liệu nhưng chúng tôi đã đề cập đến phần lớn các khía cạnh mà bạn nên xem xét khi kiến trúc môi trường cơ sở dữ liệu của mình và chúng tôi hy vọng bạn sẽ thấy hướng dẫn này hữu ích.
