एप्लिकेशन, कनेक्शन पूलिंग और पोस्टग्रेएसक्यूएल के लिए एक सुरक्षा प्रणाली - एलडीएपी के लिए मामला

परंपरागत रूप से, विशिष्ट अनुप्रयोग में निम्नलिखित घटक होते हैं:

इस साधारण मामले में, एक बुनियादी सेटअप पर्याप्त होगा:

• एप्लिकेशन अपने उपयोगकर्ताओं के लिए एक साधारण स्थानीय प्रमाणीकरण तंत्र का उपयोग करता है
• एप्लिकेशन एक साधारण कनेक्शन पूल का उपयोग करता है
• डेटाबेस एक्सेस के लिए परिभाषित एक एकल उपयोगकर्ता है

हालांकि, जैसे-जैसे संगठन विकसित होता है और बड़ा होता जाता है और अधिक घटक जोड़े जाते हैं:

• डेटाबेस तक पहुंचने वाले ऐप के अधिक टैनेंट ऐप्स या इंस्टेंस
• डेटाबेस तक पहुंचने वाली अधिक सेवाएं और सिस्टम
• सभी (या अधिकतर) सेवाओं के लिए केंद्रीय प्रमाणीकरण/प्राधिकरण (एए)
• भविष्य में आसान स्केलिंग के लिए घटकों को अलग करना

उपरोक्त योजना में, सभी चिंताओं को अलग-अलग घटकों में विभाजित किया गया है, प्रत्येक घटक एक विशेष उद्देश्य को पूरा करता है। हालाँकि, अभी भी कनेक्शन पूल एक समर्पित डेटाबेस उपयोगकर्ता का उपयोग करता है जैसा कि पिछले सरल सेटअप में हमने ऊपर देखा था।

नए घटकों के अलावा, नई आवश्यकताएं भी आती हैं:

• डेटाबेस स्तर पर उपयोगकर्ता क्या कर सकते हैं, इसका बेहतर बारीक नियंत्रण
• लेखा परीक्षा
• बेहतर अधिक उपयोगी सिस्टम लॉगिंग

हम एप्लिकेशन में अधिक एप्लिकेशन कोड या अधिक परतों के साथ तीनों को हमेशा लागू कर सकते हैं, लेकिन यह केवल बोझिल और बनाए रखने में कठिन है।

इसके अलावा, PostgreSQL उपरोक्त क्षेत्रों (सुरक्षा, पंक्ति स्तर सुरक्षा, ऑडिटिंग, आदि) पर समाधानों का इतना समृद्ध सेट प्रदान करता है कि उन सभी सेवाओं को डेटाबेस परत पर ले जाने के लिए यह सही समझ में आता है। उन सेवाओं को सीधे डेटाबेस से लेने के लिए, हमें डेटाबेस में एकल उपयोगकर्ता के बारे में भूल जाना चाहिए और इसके बजाय वास्तविक व्यक्तिगत उपयोगकर्ताओं का उपयोग करना चाहिए।

यह हमें नीचे की तरह एक योजना में ले जाता है:

हमारे उपयोग के मामले में हम उपरोक्त योजना से युक्त एक विशिष्ट उद्यम सेटअप का वर्णन करेंगे जहां हम उपयोग करते हैं:

• वाइल्डफ्लाई ऐप सर्वर (संस्करण 10 के लिए दिखाए गए उदाहरण)
• एलडीएपी प्रमाणीकरण/प्राधिकरण सेवा
• pgbouncer कनेक्शन पूलर
• पोस्टग्रेएसक्यूएल 10

यह एक सामान्य सेटअप की तरह लगता है, क्योंकि jboss/wildfly कई वर्षों से LDAP प्रमाणीकरण और प्राधिकरण का समर्थन कर रहा है, PostgreSQL कई वर्षों से LDAP का समर्थन कर रहा है।

हालाँकि, pgbouncer ने 2017 के अंत में संस्करण 1.8 के बाद से केवल LDAP (और PAM के माध्यम से) के लिए समर्थन शुरू किया, जिसका अर्थ है कि तब तक कोई व्यक्ति ऐसे एंटरप्राइज़ सेटअप में सबसे हॉट PostgreSQL कनेक्शन पूलर का उपयोग नहीं कर सकता था (जो हमारे द्वारा चुने गए किसी भी कोण से आशाजनक नहीं लगता था) इसे देखने के लिए)!

इस ब्लॉग में, हम प्रत्येक परत में आवश्यक सेटअप का वर्णन करेंगे।

वाइल्डफ्लाई 10 कॉन्फ़िगरेशन

डेटा स्रोत कॉन्फ़िगरेशन को इस तरह दिखना होगा, मैं सबसे महत्वपूर्ण सामग्री दिखा रहा हूं:

<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>

मैंने महत्वपूर्ण मापदंडों और मूल्यों को बोल्ड किया है। अपने pgbouncer सर्वर के सेटअप के अनुसार IP पता (या होस्टनाम), डेटाबेस नाम और पोर्ट को परिभाषित करना याद रखें।

साथ ही, विशिष्ट उपयोगकर्ता नाम/पासवर्ड के बजाय, आपके पास एक सुरक्षा डोमेन परिभाषित होना चाहिए, जिसे ऊपर दिखाए गए डेटा स्रोत अनुभाग में निर्दिष्ट किया जाना चाहिए। इसकी परिभाषा इस तरह दिखेगी:

<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>

इस तरह वाइल्डफ्लाई सुरक्षा संदर्भ को pgbouncer को सौंप देगा।

नोट: इस ब्लॉग में हम मूल बातें शामिल करते हैं, यानी हम टीएलएस का कोई उपयोग या उल्लेख नहीं करते हैं, हालांकि आपको इसे अपने इंस्टॉलेशन में उपयोग करने के लिए दृढ़ता से प्रोत्साहित किया जाता है।

वाइल्डफ्लाई उपयोगकर्ताओं को आपके एलडीएपी सर्वर से निम्नानुसार प्रमाणित करना होगा:

<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>

उपरोक्त कॉन्फ़िगरेशन फ़ाइलें वाइल्डफ्लाई 10.0 पर लागू होती हैं, आपको किसी भी मामले में अपने पर्यावरण के लिए आधिकारिक दस्तावेज़ीकरण से परामर्श करने की सलाह दी जाती है।

PostgreSQL कॉन्फ़िगरेशन

PostgreSQL को प्रमाणित करने के लिए कहने के लिए (नोट: अधिकृत नहीं!) अपने LDAP सर्वर के विरुद्ध आपको postgresql.conf और pg_hba.conf में उपयुक्त परिवर्तन करने होंगे। रुचि की प्रविष्टियाँ निम्नलिखित हैं:

Postgresql.conf में:

listen_addresses = '*'

और 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"

सुनिश्चित करें कि यहां परिभाषित एलडीएपी सेटिंग्स ठीक उसी से मेल खाती हैं जिसे आपने अपने ऐप सर्वर कॉन्फ़िगरेशन में परिभाषित किया था। ऑपरेशन के दो तरीके हैं जिनसे PostgreSQL को LDAP सर्वर से संपर्क करने का निर्देश दिया जा सकता है:

• साधारण बाँध
• खोजें और फिर आबद्ध करें

सरल बाइंड मोड के लिए एलडीएपी सर्वर से केवल एक कनेक्शन की आवश्यकता होती है इसलिए यह तेज़ है लेकिन दूसरे मोड की तुलना में किसी भी तरह से कठोर एलडीएपी शब्दकोश संगठन की आवश्यकता है। खोज और बाइंड मोड अधिक लचीलेपन की अनुमति देता है। हालांकि, औसत एलडीएपी निर्देशिका के लिए, पहला मोड (सरल बाइंड) ठीक काम करेगा। हमें PostgreSQL LDAP प्रमाणीकरण के बारे में कुछ बिंदुओं को रेखांकित करना चाहिए:

• इसका संबंध केवल प्रमाणीकरण से है (पासवर्ड जाँच रहा है)।
• PostgreSQL में भूमिका सदस्यता अभी भी हमेशा की तरह की जाती है।
• उपयोगकर्ताओं को हमेशा की तरह PostgreSQL (क्रिएट यूजर/भूमिका के माध्यम से) में बनाया जाना चाहिए।

LDAP और PostgreSQL उपयोगकर्ताओं (जैसे ldap2pg) के बीच सिंक्रनाइज़ेशन में मदद करने के लिए कुछ समाधान हैं या आप बस अपना खुद का रैपर लिख सकते हैं जो उपयोगकर्ताओं को जोड़ने या हटाने के लिए LDAP और PostgreSQL दोनों को संभालेगा।

PgBouncer कॉन्फ़िगरेशन

यह हमारे सेटअप का सबसे कठिन हिस्सा है, इस तथ्य के कारण कि देशी LDAP समर्थन अभी भी pgbouncer से गायब है, और एकमात्र विकल्प PAM के माध्यम से प्रमाणित करना है, जिसका अर्थ है कि यह LDAP के लिए सही स्थानीय UNIX/Linux PAM सेटअप पर निर्भर करता है।

तो प्रक्रिया दो चरणों में टूट जाती है।

पहला चरण कॉन्फ़िगर करना और परीक्षण करना है कि pgbouncer PAM के साथ काम करता है, और दूसरा चरण PAM को LDAP के साथ काम करने के लिए कॉन्फ़िगर करना है।

पीजीबाउंसर

pgbouncer को PAM समर्थन के साथ संकलित किया जाना चाहिए। ऐसा करने के लिए आपको यह करना होगा:

• libpam0g-dev इंस्टॉल करें
• ./configure --with-pam
• pgbouncer को फिर से संकलित और स्थापित करें

आपकी pgbouncer.ini (या आपकी pgbouncer कॉन्फ़िगरेशन फ़ाइल का नाम) को pam के लिए कॉन्फ़िगर किया जाना चाहिए। साथ ही, इसमें ऊपर दिए गए अनुभागों में वर्णित मापदंडों के अनुसार आपके डेटाबेस और आपके एप्लिकेशन के लिए सही पैरामीटर होने चाहिए। चीजें जिन्हें आपको परिभाषित या बदलना होगा:

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

बेशक, आपको pgbouncer डॉक्स को पढ़ना होगा और अपनी आवश्यकताओं के अनुसार अपने pgbouncer को ट्यून करना होगा। उपरोक्त सेटअप का परीक्षण करने के लिए आपको बस एक नया स्थानीय UNIX उपयोगकर्ता बनाना है और pgbouncer को प्रमाणित करने का प्रयास करना है:

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

स्थानीय पासवार्ड फाइलों से पढ़ते समय pgbouncer के लिए PAM के साथ काम करने के लिए, pgbouncer निष्पादन योग्य रूट के पास और सेटुइड के साथ होना चाहिए:

# 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

नोट:रूट स्वामित्व और सेटुइड की आवश्यकता (जो मेरे द्वारा परीक्षण किए गए प्रत्येक डेबियन/उबंटू सिस्टम के लिए सही है) कहीं भी प्रलेखित नहीं है, न ही आधिकारिक pgbouncer डॉक्स पर और न ही नेट पर कहीं भी।

फिर हम पोस्टग्रेस्क्ल होस्ट (या psql -h your.pgsql.server) में लॉगिन (pgsql सुपरयूज़र के रूप में) करते हैं और नया उपयोगकर्ता बनाते हैं:

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

फिर pgbouncer होस्ट से:

psql -h localhost -p 6432 yourdbname -U testuser

आपको एक संकेत प्राप्त करने और तालिकाओं को देखने में सक्षम होना चाहिए जैसे कि आप सीधे अपने डेटाबेस सर्वर से जुड़े थे। इस उपयोगकर्ता को सिस्टम से हटाना याद रखें और जब आप अपने सभी परीक्षण समाप्त कर लें तो डेटाबेस से भी छोड़ दें।

PAM

PAM को LDAP सर्वर के साथ इंटरफेस करने के लिए, एक अतिरिक्त पैकेज की आवश्यकता है:libpam-ldap। इसकी पोस्ट इंस्टाल स्क्रिप्ट एक टेक्स्ट मोड डायलॉग चलाएगी जिसका आपको अपने एलडीएपी सर्वर के लिए सही पैरामीटर के साथ जवाब देना होगा। यह पैकेज /etc/pam.d फाइलों में जरूरी अपडेट करेगा और एक फाइल भी बनाएगा जिसका नाम है:/etc/pam_ldap.conf। यदि भविष्य में कुछ बदलता है तो आप हमेशा वापस जा सकते हैं और इस फ़ाइल को संपादित कर सकते हैं। इस फ़ाइल में सबसे महत्वपूर्ण पंक्तियाँ हैं:

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

आपके एलडीएपी सर्वर और खोज आधार का नाम/पता बिल्कुल वैसा ही होना चाहिए जैसा कि ऊपर वर्णित PostgreSQL pg_hba.conf और Wildfly स्टैंडअलोन.xml conf फ़ाइलों में निर्दिष्ट है। pam_login_attribute डिफ़ॉल्ट रूप से uid. आपको /etc/pam.d/common-* फाइलों पर एक नजर डालने के लिए प्रोत्साहित किया जाता है और देखें कि libpam-ldap की स्थापना के बाद क्या बदल गया है। दस्तावेज़ों के बाद, आप /etc/pam.d/pgbouncer नाम की एक नई फ़ाइल बना सकते हैं और वहां सभी PAM विकल्पों को परिभाषित कर सकते हैं, लेकिन डिफ़ॉल्ट सामान्य-* फ़ाइलें पर्याप्त होंगी। आइए एक नज़र डालते हैं /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

यूनिक्स पासवार्ड को पहले चेक किया जाएगा, और यदि यह विफल रहता है तो एलडीएपी की जांच की जाएगी, इसलिए ध्यान रखें कि आपको उन उपयोगकर्ताओं के लिए किसी भी स्थानीय पासवर्ड को मिटाना होगा जो स्थानीय लिनक्स/यूनिक्स/आदि/पासवार्ड और एलडीएपी दोनों में परिभाषित हैं। . अब अंतिम परीक्षा करने का समय आ गया है। एक उपयोगकर्ता चुनें जो आपके एलडीएपी सर्वर में परिभाषित है और पोस्टग्रेएसक्यूएल में भी बनाया गया है, और डीबी से प्रमाणित करने का प्रयास करें ( pgsql -h your.pgsql.server के माध्यम से), फिर pgbouncer से (psql -h your.pgbouncer.server के माध्यम से भी) , और अंत में आपके ऐप के माध्यम से। आपने ऐप, कनेक्शन पूलर और पोस्टग्रेएसक्यूएल के लिए एक ही सुरक्षा प्रणाली को एक वास्तविकता बना दिया है!