Cơ sở dữ liệu hiện đại lưu trữ tất cả các loại dữ liệu. Từ tầm thường đến nhạy cảm cao. Các nhà hàng chúng tôi thường đến, vị trí bản đồ của chúng tôi, thông tin xác thực danh tính của chúng tôi, (ví dụ:Số an sinh xã hội, Địa chỉ, Hồ sơ y tế, Thông tin ngân hàng, v.v.) và mọi thứ ở giữa nhiều khả năng được lưu trữ trong cơ sở dữ liệu ở đâu đó. Không có gì ngạc nhiên khi dữ liệu có giá trị như vậy.
Công nghệ cơ sở dữ liệu phát triển với tốc độ chóng mặt. Đổi mới, tiến bộ, tính toàn vẹn và cải tiến rất nhiều được đặt lên hàng đầu do kết quả trực tiếp của lao động của các kỹ sư, nhà phát triển thông minh và tận tâm, cũng như cộng đồng mạnh mẽ hỗ trợ các nhà cung cấp đó.
Tuy nhiên, có một mặt khác của đồng xu. Thật không may, điều đó cùng tồn tại trong thế giới theo hướng dữ liệu này dưới dạng phần mềm độc hại, vi rút và khai thác trên quy mô lớn, mọi thời đại.
Dữ liệu cũng có giá trị đối với các bên trong hoạt động bên đó. Nhưng vì những lý do khác nhau. Bất kỳ ai trong số họ đều có thể có nhưng không giới hạn ở quyền lực, tống tiền, lợi ích tài chính và quyền truy cập, kiểm soát, vui vẻ, chơi khăm, ác ý, trộm cắp, trả thù ... Bạn có ý tưởng. Danh sách là vô tận.
Than ôi, chúng tôi phải hoạt động với tư duy bảo mật. Nếu không có tư duy này, chúng ta sẽ khiến hệ thống của mình dễ bị tấn công bởi những kiểu tấn công này. PostgreSQL cũng dễ bị xâm nhập, lạm dụng, trộm cắp, truy cập / kiểm soát trái phép như các dạng phần mềm khác.
Vậy chúng ta có thể thực hiện những biện pháp nào để giảm thiểu số lượng rủi ro đối với lượt cài đặt PostgreSQL của chúng ta?
Tôi thực sự cảm thấy rằng việc nâng cao nhận thức về những mối đe dọa đã biết ngoài kia, cũng là một nơi tốt để bắt đầu. Kiến thức là sức mạnh và chúng ta nên sử dụng tất cả những gì có sẵn theo ý mình. Bên cạnh đó, làm cách nào để chúng tôi có thể cảnh báo điều mà chúng tôi thậm chí không biết để thắt chặt bảo mật trên các phiên bản PostgreSQL đó và bảo vệ dữ liệu ở đó?
Gần đây tôi đã tìm kiếm các 'mối quan tâm' và 'mối đe dọa' về bảo mật đã biết, nhắm mục tiêu đến môi trường PostgreSQL. Tìm kiếm của tôi bao gồm các báo cáo, bài báo và bài đăng trên blog gần đây trong quý đầu tiên của năm 2018. Ngoài khung thời gian cụ thể đó, tôi đã khám phá những mối quan tâm lâu đời nổi tiếng vẫn là mối đe dọa khả thi ngày nay (cụ thể là SQL Injection), mặc dù không được đánh bóng hoặc được đánh dấu là ' được phát hiện gần đây '.
Cơ hội chụp ảnh
Đi sâu vào các cuộc tấn công cơ sở dữ liệu [Phần III]:Tại sao bức ảnh của Scarlett Johansson lại có cơ sở dữ liệu Postgres của tôi để bắt đầu khai thác Monero
Lời nói về cuộc tấn công bằng phần mềm độc hại xảo quyệt này đã trả lại nhiều 'lượt truy cập' nhất trong số các kết quả tìm kiếm khách quan của tôi.
Chúng tôi sẽ ghé thăm một trong số các bài đăng blog tuyệt vời và tóm tắt nội dung của nó. Tôi cũng đã bao gồm các bài đăng trên blog bổ sung vào cuối phần này vì vậy hãy chắc chắn và truy cập những bài đăng đó cũng như nêu chi tiết về sự xâm nhập này.
Quan sát
Thông tin từ Imperva, báo cáo cơ sở dữ liệu honeypot (StickyDB) của họ đã phát hiện ra một cuộc tấn công bằng phần mềm độc hại vào một trong các máy chủ PostgreSQL của họ. Mạng honeypot, như Imperva đặt tên cho hệ thống, được thiết kế để lừa những kẻ tấn công tấn công cơ sở dữ liệu để chúng (Imperva) có thể tìm hiểu về nó và trở nên an toàn hơn. Trong trường hợp cụ thể này, tải trọng là phần mềm độc hại mã hóa Monero, được nhúng trong ảnh của Scarlett Johansson.
Tải trọng được chuyển vào đĩa trong thời gian chạy bằng hàm lo_export. Nhưng rõ ràng, điều này xảy ra vì lo_export là một mục nhập trong pg_proc so với cách gọi trực tiếp thông thường (lo_export).
Chi tiết thú vị trực tiếp từ bài đăng trên blog ở đây để cực kỳ rõ ràng (xem bài báo được trích dẫn),
Giờ đây, kẻ tấn công có thể thực thi các lệnh hệ thống cục bộ bằng một chức năng đơn giản - fun6440002537. Hàm SQL này là một trình bao bọc để gọi một hàm ngôn ngữ C, “sys_eval”, một hàm được xuất nhỏ trong “tmp406001440” (một hàm nhị phân dựa trên sqlmapproject), về cơ bản hoạt động như proxy để gọi các lệnh shell từ máy khách SQL.
Vậy các bước tiếp theo của cuộc tấn công sẽ là gì? Một số trinh sát. Vì vậy, nó bắt đầu với việc lấy thông tin chi tiết của GPU bằng cách thực thi video lshw -c và tiếp tục cat / proc / cpuinfo để lấy thông tin chi tiết về CPU (Hình 3-4). Mặc dù điều này lúc đầu cảm thấy kỳ lạ, nhưng nó hoàn toàn có ý nghĩa khi mục tiêu cuối cùng của bạn là khai thác nhiều loại tiền điện tử yêu thích của bạn hơn, phải không?
Với sự kết hợp của quyền truy cập cơ sở dữ liệu và khả năng thực thi mã từ xa, tất cả trong khi ' bay dưới radar 'của các giải pháp giám sát, kẻ xâm phạm sau đó tải xuống tải trọng thông qua ảnh của Scarlett Johansson.
(Lưu ý:Ảnh đã bị xóa khỏi vị trí được lưu trữ của nó. Xem bài viết liên kết để biết đề cập.)
Theo báo cáo, trọng tải ở định dạng nhị phân. Mã nhị phân đó đã được thêm vào ảnh để chuyển cho ảnh thực trong quá trình tải lên, cho phép ảnh có thể xem được.
Xem Hình 6 của bài đăng về SQL chịu trách nhiệm sử dụng wget, dd và thực thi chmod cho các quyền trên tệp đã tải xuống. Sau đó, tệp đã tải xuống đó sẽ tạo một tệp thực thi khác chịu trách nhiệm thực sự khai thác Monero. Tất nhiên, sau tất cả công việc bất chính này, việc dọn dẹp và dọn dẹp nhà cửa là cần thiết.
Hình 7 mô tả SQL đang hoạt động.
Imperva khuyên bạn nên theo dõi danh sách các khu vực có khả năng vi phạm này trong phần kết thúc:
- Đề phòng các lệnh gọi PostgreSQL trực tiếp tới lo_export hoặc các lệnh gọi gián tiếp thông qua các mục nhập trong pg_proc.
- Cẩn thận với các hàm PostgreSQL gọi tới các mã nhị phân ngôn ngữ C.
- Sử dụng tường lửa để chặn lưu lượng mạng đi từ cơ sở dữ liệu của bạn đến Internet.
- Đảm bảo rằng cơ sở dữ liệu của bạn không được gán địa chỉ IP công cộng. Nếu có, chỉ hạn chế quyền truy cập vào các máy chủ tương tác với máy chủ đó (máy chủ ứng dụng hoặc máy khách do DBA sở hữu).
Imperva cũng đã thực hiện các bài kiểm tra chống vi-rút khác nhau cùng với chi tiết về cách những kẻ tấn công có thể định vị các máy chủ PostgreSQL dễ bị tấn công. Mặc dù tôi không bao gồm chúng ở đây cho ngắn gọn, hãy tham khảo bài viết để biết chi tiết đầy đủ về những phát hiện của chúng.
Đọc đề xuất
- Imperva có 2 bài viết trước đi kèm với Phần 3 (bài viết được thảo luận ở đây). Mặc dù những người đó không nhắm mục tiêu nhiều vào PostgreSQL như những gì chúng ta vừa đề cập, nhưng chúng là những bài đọc mang tính thông tin cao:
- Phần 1
- Phần 2
- Cuộc tấn công phần mềm độc hại Scarlett Johansson PostgreSQL
- Tin tặc nhắm mục tiêu vào DBs PostgreSQL với Coinminer được ẩn trong hình ảnh Scarlett Johannsson
- Một chuỗi Tin tức về hacker về việc khai thác.
Chi tiết CVE, Báo cáo và Lỗ hổng bảo mật
Tôi đã truy cập trang web này, nơi đăng các mối đe dọa bảo mật mới nhất trên cơ sở mỗi nhà cung cấp và đã phát hiện ra 4 lỗ hổng trong Quý 1 năm 2018. Trang Thông tin Bảo mật PostgreSQL cũng đã liệt kê chúng nên vui lòng tham khảo tài nguyên đó.
Mặc dù hầu hết tất cả chúng đã được giải quyết, tôi cảm thấy điều quan trọng là phải đưa chúng vào bài đăng này để nâng cao nhận thức cho người đọc, những người có thể chưa biết về chúng. Tôi cảm thấy chúng ta có thể học hỏi từ tất cả họ. Đặc biệt là theo các cách khác nhau của các lỗ hổng được phát hiện.
Chúng được liệt kê bên dưới theo thứ tự ngày xuất bản:
Tôi. Ngày xuất bản CVE-2018-1052 2018-02-09:Ngày cập nhật 3/10/2018
Tổng quan:
Lỗ hổng tiết lộ bộ nhớ trong phân vùng bảng đã được tìm thấy trong PostgreSQL 10.x trước 10.2, cho phép kẻ tấn công đã xác thực đọc các byte tùy ý của bộ nhớ máy chủ thông qua chèn có mục đích vào bảng được phân vùng.
Lỗ hổng này đã được khắc phục với việc phát hành PostgreSQL 10.2 được xác nhận tại đây. Phiên bản 9.x cũ hơn cũng được đề cập đến, vì vậy hãy truy cập liên kết đó để kiểm tra phiên bản cụ thể của bạn.
II. Ngày xuất bản CVE-2018-1053 2018-02-09:Ngày cập nhật 15/03/2018
Tổng quan:
Trong PostgreSQL 9.3.x trước 9.3.21, 9.4.x trước 9.4.16, 9.5.x trước 9.5.11, 9.6.x trước 9.6.7 và 10.x trước 10.2, pg_upgrade tạo tệp trong thư mục làm việc hiện tại có chứa đầu ra của `pg_dumpall -g` dưới umask, có hiệu lực khi người dùng gọi pg_upgrade và không dưới 0077 thường được sử dụng cho các tệp tạm thời khác. Điều này có thể cho phép kẻ tấn công đã xác thực đọc hoặc sửa đổi một tệp, tệp này có thể chứa mật khẩu cơ sở dữ liệu được mã hóa hoặc không được mã hóa. Cuộc tấn công không thể thực hiện được nếu chế độ thư mục chặn kẻ tấn công tìm kiếm thư mục làm việc hiện tại hoặc nếu umask phổ biến chặn kẻ tấn công mở tệp.
Giống như CVE-2018-1052 trước đó, PostgreSQL 10.2 đã sửa phần lỗ hổng này:
Đảm bảo rằng tất cả các tệp tạm thời được tạo bằng "pg_upgrade" đều không thể đọc được
Nhiều phiên bản cũ của PostgreSQL bị ảnh hưởng bởi lỗ hổng này. Hãy chắc chắn và truy cập liên kết được cung cấp cho tất cả các phiên bản được liệt kê đó.
III. Ngày xuất bản CVE-2017-14798 2018-03-01:Ngày cập nhật 26/3/2018
Tổng quan:
Một điều kiện chủng tộc trong tập lệnh PostgreSQL init có thể được sử dụng bởi những kẻ tấn công có thể truy cập vào tài khoản PostgreSQL để nâng cấp đặc quyền của chúng lên root.
Mặc dù tôi không thể tìm thấy bất kỳ nơi nào trên trang liên kết mà PostgreSQL phiên bản 10 đã được đề cập, nhưng nhiều phiên bản cũ hơn, vì vậy hãy truy cập liên kết đó nếu đang chạy các phiên bản cũ hơn.
Người dùng Suse Linux Enterprise Server có thể quan tâm đến 2 bài viết được liên kết tại đây và đây nơi lỗ hổng bảo mật này đã được sửa cho phiên bản 9.4 init script.
IV. Ngày xuất bản CVE-2018-1058 2018-03-02:Ngày cập nhật 22/02/2018
Tổng quan:
Một lỗ hổng đã được tìm thấy trong cách PostgreSQL cho phép người dùng sửa đổi hành vi của một truy vấn cho những người dùng khác. Kẻ tấn công có tài khoản người dùng có thể sử dụng lỗ hổng này để thực thi mã với quyền của người dùng cấp cao trong cơ sở dữ liệu. Các phiên bản 9.3 đến 10 bị ảnh hưởng.
Bản phát hành cập nhật này đề cập đến lỗ hổng này với một tài liệu được liên kết thú vị mà tất cả người dùng nên truy cập.
Bài viết cung cấp một hướng dẫn tuyệt vời từ cộng đồng có tiêu đề Hướng dẫn về CVE-2018-1058:Bảo vệ Đường dẫn Tìm kiếm của bạn, có một lượng thông tin đáng kinh ngạc liên quan đến lỗ hổng, rủi ro và các phương pháp hay nhất để chống lại nó.
Tôi sẽ cố gắng hết sức để tóm tắt, nhưng hãy truy cập hướng dẫn vì lợi ích, sự hiểu biết và sự hiểu biết của riêng bạn.
Tổng quan:
Với sự ra đời của PostgreSQL phiên bản 7.3, các lược đồ đã được đưa vào hệ sinh thái. Cải tiến này cho phép người dùng tạo các đối tượng trong các không gian tên riêng biệt. Theo mặc định, khi người dùng tạo cơ sở dữ liệu, PostgreSQL cũng tạo một lược đồ công khai trong đó tất cả các đối tượng mới được tạo. Người dùng có thể kết nối với cơ sở dữ liệu cũng có thể tạo các đối tượng trong lược đồ công khai của cơ sở dữ liệu đó.
Phần này trực tiếp từ hướng dẫn rất quan trọng (xem bài báo được trích dẫn):
Các lược đồ cho phép người sử dụng các đối tượng không gian tên, vì vậy các đối tượng cùng tên có thể tồn tại trong các lược đồ khác nhau trong cùng một cơ sở dữ liệu. Nếu có các đối tượng có cùng tên trong các lược đồ khác nhau và cặp lược đồ / đối tượng cụ thể không được chỉ định (tức là schema.object), thì PostgreSQL sẽ quyết định đối tượng nào sẽ sử dụng dựa trên cài đặt search_path. Cài đặt search_path chỉ định thứ tự các lược đồ được tìm kiếm khi tìm kiếm một đối tượng. Giá trị mặc định cho search_path là $ user, công khai trong đó $ user đề cập đến tên của người dùng được kết nối (có thể được xác định bằng cách thực thi SELECT SESSION_USER;).
Một điểm quan trọng khác nằm ở đây:
Sự cố được mô tả trong CVE-2018-1058 xoay quanh lược đồ "công khai" mặc định và cách PostgreSQL sử dụng cài đặt search_path. Khả năng tạo các đối tượng có cùng tên trong các lược đồ khác nhau, kết hợp với cách PostgreSQL tìm kiếm các đối tượng trong các lược đồ, tạo cơ hội cho người dùng sửa đổi hành vi của truy vấn cho người dùng khác.
Dưới đây là danh sách cấp cao mà hướng dẫn khuyến nghị áp dụng các phương pháp này theo quy định để giảm nguy cơ bị tổn thương này:
- Không cho phép người dùng tạo các đối tượng mới trong lược đồ công khai
- Đặt search_path mặc định cho người dùng cơ sở dữ liệu
- Đặt search_path mặc định trong tệp cấu hình PostgreSQL (postgresql.conf)
SQL Injection
Bất kỳ ' chủ đề bảo mật nào 'Bài đăng hoặc bài báo trên blog SQL không thể tự gắn nhãn như vậy nếu không đề cập đến SQL injection. Mặc dù phương pháp tấn công này không có gì ngoài sức tưởng tượng ' đứa trẻ mới vào nghề ', nó phải được bao gồm.
SQL Injection luôn là một mối đe dọa và có lẽ còn hơn thế nữa trong không gian ứng dụng web. Bất kỳ cơ sở dữ liệu SQL nào - bao gồm cả PostgreSQL- đều có thể dễ bị tấn công.
Mặc dù tôi không có cơ sở kiến thức sâu về SQL Injection - hay còn được gọi là SQLi- tôi sẽ cố gắng hết sức để cung cấp một bản tóm tắt ngắn gọn, nó có thể ảnh hưởng như thế nào đến máy chủ PostgreSQL của bạn và cuối cùng là cách giảm thiểu rủi ro khi trở thành con mồi với nó.
Hãy tham khảo các liên kết được cung cấp ở cuối phần này, tất cả đều chứa nhiều thông tin, giải thích và ví dụ về những lĩnh vực mà tôi không thể giao tiếp đầy đủ.
Thật không may, một số kiểu chèn SQL tồn tại và tất cả chúng đều có chung mục đích là chèn SQL gây khó chịu vào các truy vấn để thực thi trong cơ sở dữ liệu, có lẽ không phải mục đích ban đầu cũng như không được thiết kế bởi nhà phát triển.
Đầu vào của người dùng không được vệ sinh, kiểm tra loại được thiết kế kém hoặc không tồn tại (xác thực AKA), cùng với đầu vào của người dùng không thoát, tất cả đều có thể để lại cánh cửa rộng mở cho những kẻ tấn công. Nhiều API lập trình web cung cấp một số biện pháp bảo vệ chống lại SQLi:ví dụ:ORM (Object Relational Mapper), truy vấn tham số hóa, kiểm tra kiểu, v.v. những chuyển hướng và cơ chế đó theo ý của họ.
Dưới đây là những gợi ý đáng chú ý để giảm nguy cơ bị chèn SQL từ Bảng lừa đảo ngăn chặn sự xâm nhập SQL của OWASP. Hãy chắc chắn và truy cập nó để biết đầy đủ các ví dụ chi tiết sử dụng trong thực tế (xem bài báo được trích dẫn).
Phòng thủ chính:
- Tùy chọn 1:Sử dụng các câu lệnh soạn sẵn (với các truy vấn được tham số hóa)
- Tùy chọn 2:Sử dụng các thủ tục đã lưu trữ
- Tùy chọn 3:Xác thực đầu vào danh sách trắng
- Tùy chọn 4:Bỏ qua tất cả thông tin nhập do người dùng cung cấp
Phòng thủ bổ sung:
- Ngoài ra:Thực thi Đặc quyền Ít nhất
- Ngoài ra:Thực hiện xác thực đầu vào danh sách trắng như một biện pháp bảo vệ thứ cấp
Đọc được đề xuất:
Tôi đã bao gồm các bài báo bổ sung với vô số thông tin để nghiên cứu thêm và nâng cao nhận thức:
- Chèn SQL là gì? Thiết bị cũ nhưng tốt này có thể khiến các ứng dụng web của bạn bị tổn thương
- Chèn SQL (Wikipedia)
- Chèn SQL (CLOUDFLARE)
- SQL Injection (w3schools.com)
- Trang tính gian lận ngăn chặn sự xâm nhập SQL
- Kiểm tra SQL Injection
- Các lỗ hổng SQL Injection và Cách Ngăn chặn Chúng
- Trang tính Cheat Chèn SQL
Đặc quyền của vai trò Postgres
Chúng tôi có một câu nói cho điều gì đó dọc theo dòng " Chúng tôi là kẻ thù tồi tệ nhất của chính chúng tôi . "
Chúng tôi chắc chắn có thể áp dụng nó để làm việc trong môi trường PostgreSQL. Sự lơ là, hiểu lầm hoặc thiếu cẩn trọng cũng là cơ hội cho các cuộc tấn công và sử dụng trái phép giống như những hành động cố ý được đưa ra.
Có lẽ còn hơn thế nữa, vô tình cho phép các bên vi phạm tiếp cận dễ dàng hơn, các tuyến đường và kênh tiếp cận dễ dàng hơn.
Tôi sẽ đề cập đến một lĩnh vực luôn cần được đánh giá lại hoặc đánh giá lại theo thời gian.
Đặc quyền vai trò không chính đáng hoặc không liên quan.
- SUPERUSER
- CREATROLE
- CREATEDB
- CẤP
Sự kết hợp các đặc quyền này chắc chắn đáng để xem. SUPERUSER và CREATROLE là những lệnh cực kỳ mạnh mẽ và sẽ được phân phối tốt hơn trong tay của một DBA trái ngược với một nhà phân tích hoặc nhà phát triển, bạn có nghĩ vậy không?
Vai trò có thực sự cần thuộc tính CREATEDB không? Còn GRANT thì sao? Thuộc tính đó có khả năng bị kẻ xấu lạm dụng.
Cân nhắc nặng nề tất cả các tùy chọn trước khi cho phép các thuộc tính này đóng vai trò trong môi trường của bạn.
Chiến lược, Phương pháp hay nhất và Sự củng cố
Dưới đây là danh sách các bài đăng blog, bài báo, danh sách kiểm tra và hướng dẫn hữu ích được trả về kết quả tìm kiếm 'một năm trở lại' (tại thời điểm viết bài này). Chúng không được liệt kê theo bất kỳ thứ tự quan trọng nào và mỗi đề xuất đều đưa ra những gợi ý đáng chú ý.
- Các cách đơn giản để bảo vệ máy chủ Postgres của bạn khỏi một vectơ tấn công không đáng có:Hình ảnh giả mạo của Scarlett Johansson
- Giúp bảo mật Cơ sở dữ liệu PostgreSQL của bạn
- Đừng cố chấp ... Hãy quản lý cơ sở dữ liệu PostgreSQL của bạn để đảm bảo an ninh
- Cách bảo mật Cơ sở dữ liệu PostgreSQL của bạn - 10 Mẹo
- Bảo mật PostgreSQL khỏi Tấn công bên ngoài
- Các đặc quyền và bảo mật của PostgreSQL - Khóa giản đồ công khai
Kết luận
Trong blog này, chúng ta đã điểm qua các vấn đề bảo mật mà quản trị viên PostgreSQL trên toàn cầu quan tâm:những vấn đề đó bao gồm SQL injection, đây là chén thánh của tất cả các sự cố bảo mật, sơ suất về các cách tiếp cận cơ bản để xử lý dữ liệu an toàn, chẳng hạn như không thắt chặt quyền trên cơ sở hạ tầng của bạn một cách hợp lý và một số vấn đề bảo mật ít được biết đến hơn có thể bị bỏ qua. Khi vấn đề bảo mật dữ liệu của chúng tôi được quan tâm, điều quan trọng là chúng tôi phải thực hiện và áp dụng lời khuyên từ các bên đáng tin cậy như Imperva và những bên tương tự, những bên cung cấp cho chúng tôi các cách để bảo vệ bản thân khỏi các cuộc tấn công cơ bản và từ 0 ngày (các vụ khai thác chưa được đã biết trước đây) như nhau, bởi vì lời khuyên có uy tín có nghĩa là một tương lai tốt đẹp cho toàn bộ cơ sở dữ liệu và cơ sở hạ tầng của chúng tôi.
Hãy nhớ rằng các biện pháp bảo mật mà chúng ta cần thực hiện sẽ phụ thuộc rất nhiều vào các lỗ hổng mà chúng ta muốn chống lại, nhưng nói chung, biết tất cả các biện pháp phòng thủ cần thiết để chống lại SQL injection, sử dụng đúng cách đặc quyền và luôn cố gắng giảm mức độ rủi ro của chúng tôi liên quan đến các lỗ hổng bảo mật là rất quan trọng. Luôn cập nhật những gì đang xảy ra trong không gian bảo mật PostgreSQL cũng sẽ khiến chúng ta tự hỏi:chúng ta chỉ có thể bảo vệ máy chủ của mình (và do đó, dữ liệu của chúng ta) nếu chúng ta biết những gì kẻ tấn công có thể theo đuổi.
Nếu bạn đang tìm kiếm thêm các phương pháp hay nhất để cải thiện tình trạng bảo mật hoặc hiệu suất của các cài đặt PostgreSQL của mình, hãy chuyển sang sử dụng ClusterControl:vì công cụ này được phát triển bởi các chuyên gia cơ sở dữ liệu hàng đầu từ khắp nơi trên thế giới, nó sẽ làm cho cơ sở dữ liệu của bạn hót ngay lập tức. Sản phẩm cũng đi kèm với bản dùng thử miễn phí 30 ngày, vì vậy hãy đảm bảo bạn không bỏ lỡ việc thử tất cả các tính năng mà ClusterControl có thể cung cấp cho doanh nghiệp của bạn và hãy thử ngay hôm nay.
Để biết thêm nội dung về cách bạn nên tiếp tục bảo mật các phiên bản cơ sở dữ liệu PostgreSQL của mình, hãy truy cập blog của vài người để được tư vấn:học cách tự động kiểm tra bảo mật cho PostgreSQL chắc chắn sẽ là một bước đi đúng hướng. Đảm bảo theo dõi chúng tôi trên Twitter, LinkedIn và đăng ký nguồn cấp dữ liệu RSS của chúng tôi để biết thêm thông tin cập nhật và chúng tôi sẽ gặp bạn trong bài viết tiếp theo.
