Hướng dẫn kiểm tra cơ sở dữ liệu nguồn mở DevOps - Mọi thứ bạn nên biết

Kiểm toán là việc giám sát và ghi lại các hành động đã chọn của cơ sở dữ liệu người dùng. Nó thường được sử dụng để điều tra hoạt động đáng ngờ hoặc theo dõi và thu thập dữ liệu về các hoạt động cơ sở dữ liệu cụ thể. Ví dụ:quản trị viên cơ sở dữ liệu có thể thu thập thống kê về bảng nào đang được cập nhật, số lượng hoạt động được thực hiện hoặc có bao nhiêu người dùng đồng thời kết nối vào những thời điểm cụ thể.

Trong bài đăng trên blog này, chúng tôi sẽ đề cập đến các khía cạnh cơ bản của việc kiểm tra hệ thống cơ sở dữ liệu nguồn mở của chúng tôi, đặc biệt là MySQL, MariaDB, PostgreSQL và MongoDB. Bài viết này nhắm mục tiêu đến các kỹ sư DevOps, những người thường có ít kinh nghiệm hoặc ít tiếp xúc với thực tiễn tốt nhất về tuân thủ kiểm toán và quản trị dữ liệu tốt khi quản lý cơ sở hạ tầng chủ yếu cho hệ thống cơ sở dữ liệu.

Kiểm tra bản sao kê

Kiểm tra Tuyên bố MySQL

MySQL có nhật ký truy vấn chung (hoặc general_log), về cơ bản ghi lại những gì mysqld đang làm. Máy chủ ghi thông tin vào nhật ký này khi máy khách kết nối hoặc ngắt kết nối và nó ghi lại từng câu lệnh SQL nhận được từ máy khách. Nhật ký truy vấn chung có thể rất hữu ích khi khắc phục sự cố nhưng không thực sự được xây dựng để kiểm tra liên tục. Nó có tác động lớn đến hiệu suất và chỉ nên được bật trong các khoảng thời gian ngắn. Thay vào đó, có các tùy chọn khác để sử dụng bảng performance_schema.events_statements * hoặc Trình cắm kiểm tra.

Kiểm tra Báo cáo PostgreSQL

Đối với PostgreSQL, bạn có thể bật log_statment thành "tất cả". Các giá trị được hỗ trợ cho tham số này là none (tắt), ddl, mod và all (tất cả các câu lệnh). Đối với "ddl", nó ghi lại tất cả các câu lệnh định nghĩa dữ liệu, chẳng hạn như câu lệnh CREATE, ALTER và DROP. Đối với "mod", nó ghi lại tất cả các câu lệnh DDL, cùng với các câu lệnh sửa đổi dữ liệu như INSERT, UPDATE, DELETE, TRUNCATE và COPY FROM.

Bạn có thể cần định cấu hình các tham số liên quan như log_directory, log_filename, logging_collector và log_rotation_age, như được minh họa trong ví dụ sau:

log_directory     = 'pg_log'
log_filename      = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement     = 'all'
logging_collector = on
log_rotation_age  = 10080 # 1 week in minutes 

Những thay đổi trên yêu cầu khởi động lại PostgreSQL, vì vậy hãy lập kế hoạch cẩn thận trước khi áp dụng cho môi trường sản xuất của bạn. Sau đó, bạn có thể tìm thấy các bản ghi hiện tại trong thư mục pg_log. Đối với PostgreSQL 12, vị trí là / var / lib / pgsql / 12 / data / pg_log /. Lưu ý rằng các tệp nhật ký có xu hướng phát triển nhiều theo thời gian và có thể ăn mất dung lượng ổ đĩa đáng kể. Bạn cũng có thể sử dụng log_rotation_size thay thế nếu bạn có dung lượng lưu trữ hạn chế.

Kiểm tra bản sao kê MongoDB

Đối với MongoDB, có 3 cấp độ ghi nhật ký có thể giúp chúng tôi kiểm tra các báo cáo (hoạt động hoặc hoạt động trong thuật ngữ MongoDB):

• Mức 0 - Đây là mức hồ sơ mặc định nơi trình biên dịch không thu thập bất kỳ dữ liệu nào. Mongod luôn ghi các hoạt động lâu hơn ngưỡng slowOpThresholdMs vào nhật ký của nó.

• Mức 1 - Chỉ thu thập dữ liệu cấu hình cho các hoạt động chậm. Theo mặc định, các hoạt động chậm là những hoạt động chậm hơn 100 mili giây. Bạn có thể sửa đổi ngưỡng cho các hoạt động "chậm" bằng tùy chọn thời gian chạy slowOpThresholdMs hoặc lệnh setParameter.

• Mức 2 - Thu thập dữ liệu cấu hình cho tất cả các hoạt động của cơ sở dữ liệu.

Để ghi lại tất cả các hoạt động, hãy đặt db.setProfilingLevel (2, 1000), trong đó nó sẽ lập hồ sơ tất cả các hoạt động với các hoạt động lâu hơn mili giây được xác định, trong trường hợp này là 1 giây (1000 mili giây) . Truy vấn cần tìm trong bộ sưu tập hồ sơ hệ thống cho tất cả các truy vấn mất nhiều hơn một giây, được sắp xếp theo dấu thời gian giảm dần sẽ là. Để đọc các thao tác, chúng ta có thể sử dụng truy vấn sau:

mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )

Ngoài ra, còn có dự án Mongotail, giúp đơn giản hóa quy trình lập hồ sơ hoạt động bằng một công cụ bên ngoài thay vì truy vấn trực tiếp đến bộ sưu tập hồ sơ.

Hãy nhớ rằng không nên chạy kiểm tra toàn bộ báo cáo trong máy chủ cơ sở dữ liệu sản xuất vì nó thường gây ra tác động đáng kể đến dịch vụ cơ sở dữ liệu với khối lượng ghi nhật ký khổng lồ. Cách được đề xuất là sử dụng plugin kiểm tra cơ sở dữ liệu thay thế (như được hiển thị bên dưới), plugin này cung cấp một cách chuẩn để tạo nhật ký kiểm tra thường được yêu cầu để tuân thủ các chứng chỉ của chính phủ, tài chính hoặc ISO.

Kiểm tra Đặc quyền cho MySQL, MariaDB và PostgreSQL

Kiểm tra đặc quyền kiểm tra các đặc quyền và kiểm soát truy cập đối với các đối tượng cơ sở dữ liệu. Kiểm soát truy cập đảm bảo rằng người dùng truy cập cơ sở dữ liệu được xác định tích cực và có thể truy cập, cập nhật hoặc xóa dữ liệu mà họ có quyền. Khu vực này thường bị kỹ sư DevOps bỏ qua, điều này khiến cho việc cấp quyền quá mức là một lỗi phổ biến khi tạo và cấp cho người dùng cơ sở dữ liệu.

Ví dụ về quá đặc quyền là:

• Máy chủ truy cập của người dùng được phép từ một phạm vi rất rộng, ví dụ:cấp máy chủ người dùng [email protected] ' % ', thay vì một địa chỉ IP riêng lẻ.

• Đặc quyền quản trị đang được chỉ định cho người dùng cơ sở dữ liệu không phải quản trị viên, ví dụ:người dùng cơ sở dữ liệu cho ứng dụng đang được chỉ định với đặc quyền SUPER hoặc RELOAD.

• Thiếu kiểm soát tài nguyên đối với bất kỳ loại sử dụng quá mức nào như Kết nối người dùng tối đa, Truy vấn tối đa mỗi giờ hoặc Tối đa Kết nối mỗi giờ.

• Cho phép người dùng cơ sở dữ liệu cụ thể cũng truy cập vào các lược đồ khác.

Đối với MySQL, MariaDB và PostgreSQL, bạn có thể thực hiện kiểm tra đặc quyền thông qua Sơ đồ thông tin bằng cách truy vấn các bảng liên quan đến quyền, vai trò và đặc quyền. Đối với MongoDB, hãy sử dụng truy vấn sau (yêu cầu hành động của viewUser cho các cơ sở dữ liệu khác):

mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )

ClusterControl cung cấp một bản tóm tắt đẹp về các đặc quyền được gán cho người dùng cơ sở dữ liệu. Đi tới Quản lý -> Lược đồ và Người dùng -> Người dùng và bạn sẽ nhận được báo cáo về đặc quyền của người dùng, cùng với các tùy chọn nâng cao như Yêu cầu SSL, Kết nối tối đa mỗi giờ, v.v.

ClusterControl hỗ trợ kiểm tra đặc quyền cho MySQL, MariaDB và PostgreSQL dưới cùng một người dùng giao diện.

Kiểm tra Đối tượng Giản đồ

Đối tượng lược đồ là cấu trúc logic do người dùng tạo ra. Ví dụ về các đối tượng lược đồ là bảng, chỉ mục, dạng xem, quy trình, sự kiện, thủ tục, hàm, trình kích hoạt và các đối tượng khác. Về cơ bản, nó là các đối tượng chứa dữ liệu hoặc có thể chỉ bao gồm một định nghĩa. Thông thường, người ta sẽ kiểm tra các quyền được liên kết với các đối tượng lược đồ để phát hiện các cài đặt bảo mật kém và hiểu mối quan hệ và sự phụ thuộc giữa các đối tượng.

Đối với MySQL và MariaDB, có information_schema và performance_schema mà chúng ta có thể sử dụng để kiểm tra cơ bản các đối tượng lược đồ. Performance_schema là một chút chiều sâu trong thiết bị đo đạc như tên gọi của nó. Tuy nhiên, MySQL cũng bao gồm một lược đồ sys kể từ phiên bản 5.7.7, là phiên bản thân thiện với người dùng của performance_schema. Tất cả các cơ sở dữ liệu này đều có thể truy cập trực tiếp và khách hàng có thể truy vấn được.

Tiện ích / Tiện ích mở rộng Kiểm tra Cơ sở dữ liệu

Cách được khuyến nghị nhất để thực hiện kiểm tra báo cáo là sử dụng một plugin hoặc tiện ích mở rộng kiểm tra, được tạo riêng cho công nghệ cơ sở dữ liệu đang được sử dụng. MariaDB và Percona có triển khai plugin Kiểm toán của riêng họ, điều này hơi khác so với plugin Kiểm tra của MySQL có sẵn trong MySQL Enterprise. Hồ sơ đánh giá bao gồm thông tin về hoạt động đã được đánh giá, người sử dụng thực hiện hoạt động và ngày và giờ của hoạt động. Các bản ghi có thể được lưu trữ trong bảng từ điển dữ liệu, được gọi là đường dẫn kiểm tra cơ sở dữ liệu hoặc trong các tệp hệ điều hành, được gọi là đường dẫn kiểm tra hệ điều hành.

Đối với PostgreSQL, có pgAudit, một tiện ích mở rộng PostgreSQL cung cấp ghi nhật ký kiểm tra phiên và / hoặc đối tượng chi tiết thông qua cơ sở ghi nhật ký PostgreSQL tiêu chuẩn. Về cơ bản, nó là phiên bản nâng cao của tính năng log_statement của PostgreSQL với khả năng dễ dàng tìm kiếm và tra cứu dữ liệu đã thu thập để đánh giá bằng cách tuân theo nhật ký đánh giá tiêu chuẩn.

MongoDB Enterprise (trả phí) và Máy chủ Percona cho MongoDB (miễn phí) bao gồm khả năng kiểm tra các phiên bản mongod và mongos. Khi bật kiểm tra, máy chủ sẽ tạo thông báo kiểm tra có thể được đăng nhập vào nhật ký hệ thống, bảng điều khiển hoặc tệp (định dạng JSON hoặc BSON). Trong hầu hết các trường hợp, bạn nên đăng nhập vào tệp ở định dạng BSON, nơi tác động hiệu suất nhỏ hơn JSON. Tệp này chứa thông tin về các sự kiện người dùng khác nhau bao gồm xác thực, lỗi ủy quyền, v.v. Xem tài liệu Kiểm toán để biết chi tiết.

Đường mòn Kiểm tra Hệ điều hành

Việc định cấu hình các đường kiểm tra của hệ điều hành cũng rất quan trọng. Đối với Linux, mọi người thường sử dụng Auditd. Auditd là thành phần không gian người dùng của Hệ thống Kiểm toán Linux và chịu trách nhiệm ghi các bản ghi kiểm tra vào đĩa. Việc xem nhật ký được thực hiện bằng các tiện ích ausearch hoặc aureport. Việc định cấu hình các quy tắc kiểm tra được thực hiện bằng tiện ích Auditctl hoặc bằng cách sửa đổi trực tiếp các tệp quy tắc.

Các bước cài đặt sau là phương pháp phổ biến của chúng tôi khi thiết lập bất kỳ loại máy chủ nào để sử dụng trong sản xuất:

$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restart

Lưu ý rằng việc khởi động lại dịch vụ kiểm toán dòng cuối cùng là bắt buộc vì kiểm tra không hoạt động thực sự tốt khi tải các quy tắc với systemd. Tuy nhiên, systemd vẫn được yêu cầu để giám sát dịch vụ Auditd. Trong khi khởi động, các quy tắc trong /etc/audit/audit.rules được kiểm toán đọc. Bản thân trình nền kiểm toán có một số tùy chọn cấu hình mà quản trị viên có thể muốn tùy chỉnh. Chúng được tìm thấy trong tệp Auditd.conf.

Dòng sau là kết quả lấy từ nhật ký kiểm tra đã định cấu hình:

$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729

Như bạn có thể thấy ở trên, có thể dễ dàng phát hiện ra mật khẩu văn bản rõ ràng cho MySQL ("--password =S3cr3tPassw0rdKP") bằng cách sử dụng tiện ích tìm kiếm như được kiểm toán viên nắm bắt. Loại phát hiện và kiểm tra này rất quan trọng để bảo mật cơ sở hạ tầng cơ sở dữ liệu của chúng tôi, nơi mật khẩu văn bản rõ ràng là không thể chấp nhận được trong môi trường an toàn.

Lời kết

Nhật ký hoặc dấu vết kiểm tra là một khía cạnh quan trọng thường bị các kỹ sư DevOps bỏ qua khi quản lý cơ sở hạ tầng và hệ thống, chưa nói đến hệ thống cơ sở dữ liệu là một hệ thống rất quan trọng để lưu trữ dữ liệu nhạy cảm và bí mật. Bất kỳ việc lộ hoặc vi phạm dữ liệu riêng tư nào của bạn đều có thể gây tổn hại vô cùng lớn cho doanh nghiệp và không ai muốn điều đó xảy ra trong thời đại công nghệ thông tin hiện nay.