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

Một hệ thống bảo mật cho ứng dụng, tổng hợp kết nối và PostgreSQL - Trường hợp cho LDAP

Theo truyền thống, ứng dụng điển hình bao gồm các thành phần sau:

Trong trường hợp đơn giản này, một thiết lập cơ bản là đủ:

  • ứng dụng sử dụng cơ chế xác thực cục bộ đơn giản cho người dùng
  • ứng dụng sử dụng một nhóm kết nối đơn giản
  • có một người dùng duy nhất được xác định để truy cập cơ sở dữ liệu

Tuy nhiên, khi tổ chức phát triển và có nhiều thành phần hơn được thêm vào:

  • nhiều ứng dụng của người thuê hơn hoặc các phiên bản của ứng dụng truy cập vào cơ sở dữ liệu
  • nhiều dịch vụ và hệ thống khác truy cập cơ sở dữ liệu
  • xác thực / ủy quyền trung tâm (AA) cho tất cả (hoặc hầu hết) dịch vụ
  • tách các thành phần để mở rộng quy mô dễ dàng hơn trong tương lai

Trong sơ đồ trên, tất cả các mối quan tâm được tách thành các thành phần riêng lẻ, mỗi thành phần phục vụ một mục đích chuyên biệt. Tuy nhiên, nhóm kết nối vẫn sử dụng một người dùng cơ sở dữ liệu chuyên dụng duy nhất như trong thiết lập đơn giản hơn trước đó mà chúng ta đã thấy ở trên.

Bên cạnh các thành phần mới, cũng có các yêu cầu mới:

  • kiểm soát chi tiết tốt hơn những gì người dùng có thể làm ở cấp cơ sở dữ liệu
  • kiểm toán
  • ghi nhật ký hệ thống hữu ích hơn tốt hơn

Chúng tôi luôn có thể triển khai cả ba với nhiều mã ứng dụng hơn hoặc nhiều lớp hơn trong ứng dụng, nhưng điều này chỉ là rườm rà và khó bảo trì.

Ngoài ra, PostgreSQL cung cấp một bộ giải pháp phong phú về các lĩnh vực đã đề cập ở trên (bảo mật, Bảo mật cấp hàng, kiểm toán, v.v.) nên việc chuyển tất cả các dịch vụ đó sang lớp cơ sở dữ liệu là rất hợp lý. Để lấy các dịch vụ đó trực tiếp từ cơ sở dữ liệu, chúng ta phải quên đi những người dùng đơn lẻ trong cơ sở dữ liệu và thay vào đó sử dụng những người dùng cá nhân thực sự.

Điều này đưa chúng ta đến một lược đồ như sau:

Trong trường hợp sử dụng của chúng tôi, chúng tôi sẽ mô tả một thiết lập doanh nghiệp điển hình bao gồm sơ đồ trên, nơi chúng tôi sử dụng:

  • Máy chủ ứng dụng Wildfly (ví dụ được hiển thị cho phiên bản 10)
  • Dịch vụ xác thực / ủy quyền LDAP
  • trình tổng hợp kết nối pgbouncer
  • PostgreSQL 10

Có vẻ như đây là một thiết lập điển hình, vì jboss / wildfly đã hỗ trợ xác thực và ủy quyền LDAP trong nhiều năm, PostgreSQL đã hỗ trợ LDAP trong nhiều năm.

Tuy nhiên pgbouncer chỉ bắt đầu hỗ trợ LDAP (và điều này thông qua PAM) kể từ phiên bản 1.8 vào cuối năm 2017, có nghĩa là ai đó cho đến thời điểm đó không thể sử dụng trình gộp kết nối PostgreSQL nóng nhất trong một thiết lập doanh nghiệp như vậy (điều này không có vẻ hứa hẹn ở bất kỳ góc độ nào mà chúng tôi chọn nhìn vào nó)!

Trong blog này, chúng tôi sẽ mô tả thiết lập cần thiết trong mỗi lớp.

Cấu hình Wildfly 10

Cấu hình nguồn dữ liệu sẽ phải trông như thế này, tôi đang hiển thị những thứ quan trọng nhất:

<xa-datasource jndi-name="java:/pgsql" pool-name="pgsqlDS" enabled="true" mcp="org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool">
	<xa-datasource-property name="DatabaseName">
		yourdbname
	</xa-datasource-property>
	<xa-datasource-property name="PortNumber">
		6432
	</xa-datasource-property>
	<xa-datasource-property name="ServerName">
		your.pgbouncer.server
	</xa-datasource-property>
	<xa-datasource-property name="PrepareThreshold">
		0
	</xa-datasource-property>
	<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
	<driver>postgresql-9.4.1212.jar</driver>
	<new-connection-sql>
		SET application_name to 'myapp';
	</new-connection-sql>
	<xa-pool>
		<max-pool-size>400</max-pool-size>
		<allow-multiple-users>true</allow-multiple-users>
	</xa-pool>
	<security>
		<security-domain>postgresqluser</security-domain>
	</security>
</xa-datasource>

Tôi đã in đậm các tham số và giá trị quan trọng. Hãy nhớ xác định địa chỉ IP (hoặc tên máy chủ), tên cơ sở dữ liệu và cổng theo thiết lập của máy chủ pgbouncer của bạn.

Ngoài ra, thay vì tên người dùng / mật khẩu thông thường, bạn sẽ phải xác định miền bảo mật, miền này phải được chỉ định trong phần nguồn dữ liệu như được hiển thị ở trên. Định nghĩa của nó sẽ giống như sau:

<security-domain name="postgresqluser">
	<authentication>
		<login-module code="org.picketbox.datasource.security.CallerIdentityLoginModule" flag="required">
			<module-option name="managedConnectionFactoryName" value="name=pgsql,jboss.jca:service=XATxCM"/>
		</login-module>
	</authentication>
</security-domain>

Bằng cách này, wildfly sẽ ủy quyền ngữ cảnh bảo mật cho pgbouncer.

LƯU Ý: trong blog này, chúng tôi đề cập đến những điều cơ bản, tức là chúng tôi không sử dụng hoặc đề cập đến TLS, tuy nhiên, bạn được khuyến khích sử dụng nó trong quá trình cài đặt của mình.

Người dùng wildfly phải xác thực với máy chủ LDAP của bạn như sau:

<login-module code="<your login module class>" flag="sufficient">
	<module-option name="java.naming.provider.url" value="ldap://your.ldap.server/"/>
	<module-option name="java.naming.security.authentication" value="simple"/>
	<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
	<module-option name="principalDNPrefix" value="uid="/>
	<module-option name="uidAttributeID" value="memberOf"/>
	<module-option name="roleNameAttributeID" value="cn"/>
	<module-option name="roleAttributeID" value="memberOf"/>
	<module-option name="principalDNSuffix"
	value=",cn=users,cn=accounts,dc=yourorgname,dc=com"/>
	<module-option name="userSrchBase" value="dc=yourorgname,dc=com"/>
	<module-option name="rolesCtxDN"
	value="cn=groups,cn=accounts,dc=yourorgname,dc=com"/>
	<module-option name="matchOnUserDN" value="true"/>
	<module-option name="unauthendicatedIdentity" value="foousr"/>
	<module-option name="com.sun.jndi.ldap.connect.timeout" value="5000"/>
</login-module>

Các tệp cấu hình trên áp dụng cho wildfly 10.0, trong mọi trường hợp, bạn nên tham khảo tài liệu chính thức cho môi trường của mình.

Cấu hình PostgreSQL

Để yêu cầu PostgreSQL xác thực ( LƯU Ý: không ủy quyền!) chống lại máy chủ LDAP của bạn, bạn phải thực hiện các thay đổi thích hợp đối với postgresql.conf và pg_hba.conf. Các mục được quan tâm như sau:

Trong postgresql.conf:

listen_addresses = '*'

và trong pg_hba.conf:

#TYPE  DATABASE    USER        CIDR-ADDRESS                  METHOD
host    all         all         ip.ofYourPgbouncer.server/32 ldap ldapserver=your.ldap.server ldapprefix="uid=" ldapsuffix=",cn=users,cn=accounts,dc=yourorgname,dc=com"

Đảm bảo cài đặt LDAP được xác định ở đây khớp chính xác với những cài đặt bạn đã xác định trong cấu hình máy chủ ứng dụng của mình. Có hai chế độ hoạt động mà PostgreSQL có thể được hướng dẫn để liên hệ với máy chủ LDAP:

  • ràng buộc đơn giản
  • tìm kiếm và sau đó liên kết

Chế độ liên kết đơn giản chỉ yêu cầu một kết nối với máy chủ LDAP, do đó nó nhanh hơn nhưng yêu cầu tổ chức từ điển LDAP bằng cách nào đó chặt chẽ hơn so với chế độ thứ hai. Chế độ tìm kiếm và liên kết cho phép linh hoạt hơn. Tuy nhiên, đối với thư mục LDAP trung bình, chế độ đầu tiên (liên kết đơn giản) sẽ hoạt động tốt. Chúng tôi phải nhấn mạnh một số điểm nhất định về xác thực LDAP PostgreSQL:

  • Điều này liên quan đến chỉ xác thực (kiểm tra mật khẩu).
  • Tư cách thành viên vai trò vẫn được thực hiện trong PostgreSQL, như thường lệ.
  • Người dùng phải được tạo trong PostgreSQL (thông qua CREATE người dùng / vai trò) như bình thường.

Có một số giải pháp giúp đồng bộ hóa giữa người dùng LDAP và PostgreSQL (ví dụ:ldap2pg) hoặc bạn có thể chỉ cần viết trình bao bọc của riêng mình sẽ xử lý cả LDAP và PostgreSQL để thêm hoặc xóa người dùng.

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Cấu hình PgBouncer

Đây là phần khó nhất trong quá trình thiết lập của chúng tôi, do thực tế là pgbouncer vẫn còn thiếu hỗ trợ LDAP gốc và tùy chọn duy nhất là xác thực qua PAM, có nghĩa là điều này phụ thuộc vào thiết lập PAM UNIX / Linux cục bộ chính xác cho LDAP.

Vì vậy, quy trình được chia thành hai bước.

Bước đầu tiên là định cấu hình và kiểm tra xem pgbouncer có hoạt động với PAM hay không và bước thứ hai là định cấu hình PAM để hoạt động với LDAP.

pgbouncer

pgbouncer phải được biên dịch với sự hỗ trợ của PAM. Để làm như vậy, bạn sẽ phải:

  • cài đặt libpam0g-dev
  • ./configure --with-pam
  • biên dịch lại và cài đặt pgbouncer

Pgbouncer.ini của bạn (hoặc tên tệp cấu hình pgbouncer của bạn) phải được định cấu hình cho pam. Ngoài ra, nó phải chứa các tham số chính xác cho cơ sở dữ liệu và ứng dụng của bạn phù hợp với các tham số được mô tả trong các phần ở trên. Những điều bạn sẽ phải xác định hoặc thay đổi:

yourdbname = host=your.pgsql.server dbname=yourdbname pool_size=5
listen_addr = *
auth_type = pam
# set pool_mode for max performance
pool_mode = transaction
# required for JDBC
ignore_startup_parameters = extra_float_digits

Tất nhiên, bạn sẽ phải đọc tài liệu về pgbouncer và điều chỉnh pgbouncer theo nhu cầu của bạn. Để kiểm tra thiết lập ở trên, tất cả những gì bạn phải làm là tạo một người dùng UNIX cục bộ mới và cố gắng xác thực với pgbouncer:

# adduser testuser
<answer to all question, including password>

Để pgbouncer hoạt động với PAM khi đọc từ các tệp mật khẩu cục bộ, tệp thực thi pgbouncer phải được sở hữu bởi root và với setuid:

# chown root:staff ~pgbouncer/pgbouncer-1.9.0/pgbouncer     
# chmod +s ~pgbouncer/pgbouncer-1.9.0/pgbouncer
# ls -l ~pgbouncer/pgbouncer-1.9.0/pgbouncer           
-rwsrwsr-x 1 root staff 1672184 Dec 21 16:28 /home/pgbouncer/pgbouncer-1.9.0/pgbouncer

Lưu ý: Sự cần thiết đối với quyền sở hữu root và setuid (điều này đúng với mọi hệ thống debian / ubuntu mà tôi đã thử nghiệm) không có ở đâu được ghi lại, không có trên tài liệu pgbouncer chính thức hay bất kỳ nơi nào trên mạng.

Sau đó, chúng tôi đăng nhập (dưới dạng pgsql superuser) vào máy chủ postgresql (hoặc psql -h your.pgsql.server) và tạo người dùng mới:

CREATE USER testuser PASSWORD 'same as the UNIX passwd you gave above';

sau đó từ máy chủ pgbouncer:

psql -h localhost -p 6432 yourdbname -U testuser

Bạn sẽ có thể nhận được lời nhắc và xem các bảng như thể bạn được kết nối trực tiếp với máy chủ cơ sở dữ liệu của mình. Hãy nhớ xóa người dùng này khỏi hệ thống và cũng xóa khỏi cơ sở dữ liệu khi bạn hoàn thành tất cả các bài kiểm tra của mình.

PAM

Để PAM giao tiếp với máy chủ LDAP, cần có một gói bổ sung:libpam-ldap. Tập lệnh cài đặt bài đăng của nó sẽ chạy một hộp thoại chế độ văn bản mà bạn sẽ phải trả lời với các tham số chính xác cho máy chủ LDAP của mình. Gói này sẽ thực hiện các cập nhật cần thiết trong tệp /etc/pam.d và cũng tạo tệp có tên:/etc/pam_ldap.conf. Trong trường hợp có gì đó thay đổi trong tương lai, bạn luôn có thể quay lại và chỉnh sửa tệp này. Các dòng quan trọng nhất trong tệp này là:

base cn=users,cn=accounts,dc=yourorgname,dc=com
uri ldap://your.ldap.server/
ldap_version 3
pam_password crypt

Tên / địa chỉ của máy chủ LDAP của bạn và cơ sở tìm kiếm phải hoàn toàn giống với tên / địa chỉ được chỉ định trong tệp tin conf PostgreSQL pg_hba.conf và Wildfly standalone.xml được giải thích ở trên. pam_login_attribute mặc định là uid. Bạn nên xem các tệp /etc/pam.d/common-* và xem những gì đã thay đổi sau khi cài đặt libpam-ldap. Theo các tài liệu, bạn có thể tạo một tệp mới có tên /etc/pam.d/pgbouncer và xác định tất cả các tùy chọn PAM ở đó, nhưng các tệp common- * mặc định sẽ đủ. Hãy xem /etc/pam.d/common-auth:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Mật khẩu Unix sẽ được kiểm tra đầu tiên và nếu điều này không thành công thì LDAP sẽ được kiểm tra, vì vậy hãy nhớ rằng bạn sẽ phải xóa mọi mật khẩu cục bộ cho những người dùng được xác định cả cho linux / unix / etc / passwd cục bộ và trong LDAP . Bây giờ là lúc để làm bài kiểm tra cuối cùng. Chọn người dùng được xác định trong máy chủ LDAP của bạn và cũng được tạo trong PostgreSQL và cố gắng xác thực từ DB (qua pgsql -h your.pgsql.server), sau đó từ pgbouncer (cũng qua psql -h your.pgbouncer.server) và cuối cùng là thông qua ứng dụng của bạn. Bạn vừa biến việc có một hệ thống bảo mật duy nhất cho ứng dụng, trình kết nối kết nối và PostgreSQL thành hiện thực!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. org.postgresql.util.PSQLException:FATAL:xin lỗi, đã có quá nhiều khách hàng

  2. Tổng quan về các phương thức JOIN trong PostgreSQL

  3. Vùng chứa Spring Docker không thể truy cập vùng chứa Postgres Docker

  4. Lấy N hàng cuối cùng trong cơ sở dữ liệu theo thứ tự?

  5. Cách cài đặt PostgreSQL trên macOS