1. खास जानकारी
जनरेटिव एआई ऐप्लिकेशन बनाने की जल्दबाज़ी में, हम अक्सर सबसे ज़रूरी कॉम्पोनेंट को भूल जाते हैं: सुरक्षा.
मान लें कि आपको एक एचआर चैटबॉट बनाना है. आपको इससे "मेरी सैलरी कितनी है?" या "मेरी टीम की परफ़ॉर्मेंस कैसी है?" जैसे सवालों के जवाब चाहिए
- अगर ऐलिस (एक सामान्य कर्मचारी) अनुरोध करती है, तो उसे सिर्फ़ अपना डेटा दिखना चाहिए.
- अगर बॉब (मैनेजर) अनुरोध करता है, तो उसे अपनी टीम का डेटा दिखना चाहिए.
समस्या
ज़्यादातर RAG (Retrieval Augmented Generation) आर्किटेक्चर, इस समस्या को ऐप्लिकेशन लेयर में हल करने की कोशिश करते हैं. ये सिस्टम, जवाब के हिस्सों को वापस पाने के बाद फ़िल्टर करते हैं या एलएलएम पर "भरोसा" करते हैं. यह नाज़ुक है. अगर ऐप्लिकेशन लॉजिक काम नहीं करता है, तो डेटा लीक हो जाता है.
समाधान
सुरक्षा को डेटाबेस लेयर तक ले जाएं. AlloyDB में PostgreSQL की लाइन-लेवल की सुरक्षा (आरएलएस) का इस्तेमाल करके, हम यह पक्का करते हैं कि डेटाबेस, उपयोगकर्ता को वह डेटा न दिखाए जिसे देखने की अनुमति उसके पास नहीं है. भले ही, एआई कुछ भी पूछे.
इस गाइड में, हम "द प्राइवेट वॉल्ट" बनाएंगे. यह एक सुरक्षित एचआर असिस्टेंट है. यह इस बात के आधार पर अपने जवाबों में बदलाव करती है कि कौन लॉग इन है.
आर्किटेक्चर
हम Python में अनुमति देने के लिए, जटिल लॉजिक नहीं बना रहे हैं. हम डेटाबेस इंजन का इस्तेमाल कर रहे हैं.
- इंटरफ़ेस: यह लॉगिन की सुविधा देने वाला एक आसान Streamlit ऐप्लिकेशन है.
- एआई की सुविधा: AlloyDB AI (PostgreSQL के साथ काम करता है).
- काम करने का तरीका: हम हर ट्रांज़ैक्शन की शुरुआत में एक सेशन वैरिएबल (
app.active_user) सेट करते हैं. डेटाबेस की नीतियां, पंक्तियों को फ़िल्टर करने के लिएuser_rolesटेबल (जो आइडेंटिटी प्रोवाइडर के तौर पर काम करती है) की अपने-आप जांच करती हैं.
आपको क्या बनाना है
एचआर असिस्टेंट का सुरक्षित ऐप्लिकेशन. संवेदनशील डेटा को फ़िल्टर करने के लिए, ऐप्लिकेशन लॉजिक पर भरोसा करने के बजाय, लाइन के लेवल पर सुरक्षा (आरएलएस) को सीधे तौर पर AlloyDB डेटाबेस इंजन में लागू किया जाएगा. इससे यह पक्का होता है कि अगर आपका एआई मॉडल "भ्रमित" होता है या बिना अनुमति के डेटा को ऐक्सेस करने की कोशिश करता है, तो डेटाबेस उसे वापस नहीं देगा.
आपको क्या सीखने को मिलेगा
आपको इनके बारे में जानकारी मिलेगी:
- आरएलएस के लिए स्कीमा डिज़ाइन करने का तरीका (डेटा और पहचान को अलग करना).
- PostgreSQL की नीतियां (
CREATE POLICY) लिखने का तरीका. FORCE ROW LEVEL SECURITYका इस्तेमाल करके, "टेबल के मालिक" की छूट को कैसे बायपास करें.- उपयोगकर्ताओं के लिए "कॉन्टेक्स्ट स्विचिंग" करने वाला Python ऐप्लिकेशन कैसे बनाया जाता है.
ज़रूरी शर्तें
2. शुरू करने से पहले
प्रोजेक्ट बनाना
- Google Cloud Console में, प्रोजेक्ट चुनने वाले पेज पर जाकर, Google Cloud प्रोजेक्ट चुनें या बनाएं.
- पक्का करें कि आपके Cloud प्रोजेक्ट के लिए बिलिंग चालू हो. किसी प्रोजेक्ट के लिए बिलिंग चालू है या नहीं, यह देखने का तरीका जानें.
- आपको Cloud Shell का इस्तेमाल करना होगा. यह Google Cloud में चलने वाला कमांड-लाइन एनवायरमेंट है. Google Cloud Console में सबसे ऊपर मौजूद, Cloud Shell चालू करें पर क्लिक करें.
- Cloud Shell से कनेक्ट होने के बाद, यह देखने के लिए कि आपकी पुष्टि हो चुकी है और प्रोजेक्ट को आपके प्रोजेक्ट आईडी पर सेट किया गया है, इस कमांड का इस्तेमाल करें:
gcloud auth list
- यह पुष्टि करने के लिए कि gcloud कमांड को आपके प्रोजेक्ट के बारे में पता है, Cloud Shell में यह कमांड चलाएं.
gcloud config list project
- अगर आपका प्रोजेक्ट सेट नहीं है, तो इसे सेट करने के लिए इस निर्देश का इस्तेमाल करें:
gcloud config set project <YOUR_PROJECT_ID>
- ज़रूरी एपीआई चालू करें: लिंक पर जाएं और एपीआई चालू करें.
इसके अलावा, इसके लिए gcloud कमांड का इस्तेमाल किया जा सकता है. gcloud कमांड और उनके इस्तेमाल के बारे में जानने के लिए, दस्तावेज़ देखें.
gcloud services enable \
alloydb.googleapis.com \
compute.googleapis.com \
cloudresourcemanager.googleapis.com \
servicenetworking.googleapis.com \
aiplatform.googleapis.com
समस्याएं और उन्हें हल करने का तरीका
"घोस्ट प्रोजेक्ट" सिंड्रोम | आपने |
बिलिंग बैरिकेड | आपने प्रोजेक्ट चालू कर दिया है, लेकिन बिलिंग खाते की जानकारी नहीं दी है. AlloyDB एक हाई-परफ़ॉर्मेंस इंजन है. अगर "गैस टैंक" (बिलिंग) खाली है, तो यह शुरू नहीं होगा. |
एपीआई के डेटा को अपडेट होने में लगने वाला समय | आपने "एपीआई चालू करें" पर क्लिक किया है, लेकिन कमांड लाइन में अब भी |
कोटा क्वैग्स | अगर आपने नया ट्रायल खाता इस्तेमाल किया है, तो हो सकता है कि आपने AlloyDB इंस्टेंस के लिए क्षेत्र के हिसाब से तय किया गया कोटा पूरा कर लिया हो. अगर |
3. डेटाबेस सेटअप करना
इस लैब में, हम टेस्ट डेटा के लिए डेटाबेस के तौर पर AlloyDB का इस्तेमाल करेंगे. यह सभी संसाधनों को सेव करने के लिए, क्लस्टर का इस्तेमाल करता है. जैसे, डेटाबेस और लॉग. हर क्लस्टर में एक प्राइमरी इंस्टेंस होता है, जो डेटा का ऐक्सेस पॉइंट उपलब्ध कराता है. टेबल में असल डेटा होगा.
आइए, एक AlloyDB क्लस्टर, इंस्टेंस, और टेबल बनाएं. इसमें टेस्ट डेटासेट लोड किया जाएगा.
- उस ब्राउज़र में नीचे दिए गए बटन पर क्लिक करें या लिंक को कॉपी करें जिसमें Google Cloud Console का उपयोगकर्ता लॉग इन है.
- यह चरण पूरा होने के बाद, repo को आपके लोकल क्लाउड शेल एडिटर में क्लोन कर दिया जाएगा. इसके बाद, प्रोजेक्ट फ़ोल्डर में जाकर नीचे दिए गए कमांड को चलाया जा सकेगा. यह पक्का करना ज़रूरी है कि आप प्रोजेक्ट डायरेक्ट्री में हों:
sh run.sh
- अब यूज़र इंटरफ़ेस (टर्मिनल में लिंक पर क्लिक करके या टर्मिनल में "वेब पर झलक देखें" लिंक पर क्लिक करके) का इस्तेमाल करें.
- शुरू करने के लिए, प्रोजेक्ट आईडी, क्लस्टर, और इंस्टेंस के नाम डालें.
- जब तक लॉग स्क्रोल होते हैं, तब तक कॉफ़ी पी लें. यहां यह भी बताया गया है कि पर्दे के पीछे यह कैसे काम करता है. इसमें करीब 10 से 15 मिनट लग सकते हैं.
समस्याएं और उन्हें हल करने का तरीका
"धैर्य" की समस्या | डेटाबेस क्लस्टर, एक बड़ा इन्फ़्रास्ट्रक्चर होता है. अगर आपने पेज को रीफ़्रेश किया या Cloud Shell सेशन को बंद किया, क्योंकि वह "स्टक हो गया था", तो हो सकता है कि आपको एक "घोस्ट" इंस्टेंस मिले. यह इंस्टेंस आंशिक रूप से उपलब्ध कराया गया होता है और इसे मैन्युअल तरीके से बंद किए बिना मिटाया नहीं जा सकता. |
क्षेत्र की जानकारी मेल न खाना | अगर आपने |
ज़ॉम्बी क्लस्टर | अगर आपने किसी क्लस्टर के लिए पहले भी इसी नाम का इस्तेमाल किया था और उसे मिटाया नहीं है, तो स्क्रिप्ट में यह मैसेज दिख सकता है कि क्लस्टर का नाम पहले से मौजूद है. किसी प्रोजेक्ट में क्लस्टर के नाम अलग-अलग होने चाहिए. |
Cloud Shell का टाइम आउट होना | अगर आपका कॉफ़ी ब्रेक 30 मिनट का है, तो Cloud Shell स्लीप मोड में जा सकता है और |
4. स्कीमा प्रोविज़निंग
इस चरण में, हम इन विषयों के बारे में जानकारी देंगे:
यहां सिलसिलेवार तरीके से पूरी जानकारी दी गई है:
AlloyDB क्लस्टर और इंस्टेंस चालू होने के बाद, AlloyDB Studio के एसक्यूएल एडिटर पर जाएं. यहां एआई एक्सटेंशन चालू करें और स्कीमा उपलब्ध कराएं.
आपको इंस्टेंस बनने तक इंतज़ार करना पड़ सकता है. इसके बाद, क्लस्टर बनाते समय बनाए गए क्रेडेंशियल का इस्तेमाल करके, AlloyDB में साइन इन करें. PostgreSQL में पुष्टि करने के लिए, इस डेटा का इस्तेमाल करें:
- उपयोगकर्ता नाम : "
postgres" - डेटाबेस : "
postgres" - पासवर्ड : "
alloydb" (या क्रिएशन के समय सेट किया गया कोई भी पासवर्ड)
AlloyDB Studio में पुष्टि हो जाने के बाद, SQL कमांड को एडिटर में डाला जाता है. आखिरी विंडो के दाईं ओर मौजूद प्लस आइकॉन का इस्तेमाल करके, एक से ज़्यादा Editor विंडो जोड़ी जा सकती हैं.
एडिटर विंडो में, AlloyDB के लिए निर्देश डाले जाएंगे. इसके लिए, ज़रूरत के हिसाब से 'चलाएं', 'फ़ॉर्मैट करें', और 'मिटाएं' विकल्पों का इस्तेमाल किया जाएगा.
टेबल बनाना
हमें दो टेबल की ज़रूरत है: एक संवेदनशील डेटा (कर्मचारी) के लिए और दूसरी पहचान से जुड़े नियमों (user_roles) के लिए. नीतियों में "इनफ़िनिट रिकर्शन" गड़बड़ियों से बचने के लिए, इन्हें अलग-अलग करना ज़रूरी है.
AlloyDB Studio में, नीचे दिए गए डीडीएल स्टेटमेंट का इस्तेमाल करके टेबल बनाई जा सकती है:
-- 1. Create User Roles (The Identity Provider)
CREATE TABLE user_roles (
username TEXT PRIMARY KEY,
role TEXT -- 'employee', 'manager', 'admin'
);
INSERT INTO user_roles (username, role) VALUES
('Alice', 'employee'),
('Bob', 'manager'),
('Charlie', 'employee');
-- 2. Create the Data Table
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
name TEXT,
salary INTEGER,
performance_review TEXT
);
INSERT INTO employees (name, salary, performance_review) VALUES
('Alice', 80000, 'Alice meets expectations but needs to improve punctuality.'),
('Bob', 120000, 'Bob is a strong leader. Team morale is high.'),
('Charlie', 85000, 'Charlie exceeds expectations. Ready for promotion.');
समस्याएं और उन्हें हल करने का तरीका
कर्मचारी टेबल में भूमिकाएं तय करते समय, इनफ़िनिट रिकर्सन का पता चला | यह क्यों काम नहीं करता: अगर आपकी नीति में लिखा है कि "कर्मचारी टेबल में जाकर देखें कि मैं मैनेजर हूं या नहीं", तो डेटाबेस को नीति की जांच करने के लिए टेबल को क्वेरी करना होगा. इससे नीति फिर से ट्रिगर हो जाएगी. नतीजा: इनफ़ाइनाइट रिकर्सन का पता चला.समस्या हल करने का तरीका: हमेशा अलग लुकअप टेबल (user_roles) रखें या भूमिकाओं के लिए, डेटाबेस के असली उपयोगकर्ताओं का इस्तेमाल करें. |
डेटा की पुष्टि करें:
SELECT count(*) FROM employees;
-- Output: 3
5. सुरक्षा की सुविधा चालू करना और लागू करना
अब हम शील्ड चालू करते हैं. हम एक सामान्य "ऐप्लिकेशन उपयोगकर्ता" भी बनाएंगे, जिसका इस्तेमाल हमारा Python कोड कनेक्ट करने के लिए करेगा.
AlloyDB क्वेरी एडिटर में जाकर, यहां दिया गया एसक्यूएल स्टेटमेंट चलाएं:
-- 1. Activate RLS
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
-- 2. CRITICAL: Force RLS for Table Owners
ALTER TABLE employees FORCE ROW LEVEL SECURITY;
-- 3. Create the Application User
DO
$do$
BEGIN
IF NOT EXISTS (SELECT FROM pg_catalog.pg_roles WHERE rolname = 'app_user') THEN
CREATE ROLE app_user LOGIN PASSWORD 'password';
END IF;
END
$do$;
-- 4. Grant Access
GRANT SELECT ON employees TO app_user;
GRANT SELECT ON user_roles TO app_user;
समस्याएं और उन्हें हल करने का तरीका
postgres (सुपरयूज़र) के तौर पर टेस्टिंग करना और सारा डेटा देखना. | यह सुविधा काम क्यों नहीं करती: डिफ़ॉल्ट रूप से, आरएलएस की सुविधा टेबल के मालिक या सुपरयूज़र पर लागू नहीं होती. ये सभी नीतियों को अनदेखा करते हैं.समस्या हल करना: अगर आपकी नीतियां "काम नहीं कर रही हैं" (सभी को अनुमति दे रही हैं), तो देखें कि आपने |
6. ऐक्सेस से जुड़ी नीतियां बनाना
हम सेशन वैरिएबल (app.active_user) का इस्तेमाल करके दो नियम तय करेंगे. इन्हें बाद में, हम अपने ऐप्लिकेशन कोड से सेट करेंगे.
AlloyDB क्वेरी एडिटर में जाकर, यहां दिया गया एसक्यूएल स्टेटमेंट चलाएं:
-- Policy 1: Self-View
-- Users can see rows where their name matches the session variable
CREATE POLICY "view_own_data" ON employees
FOR SELECT
USING (name = current_setting('app.active_user', true));
-- Policy 2: Manager-View
-- Managers can see ALL rows.
CREATE POLICY "manager_view_all" ON employees
FOR SELECT
USING (
EXISTS (
SELECT 1 FROM user_roles
WHERE username = current_setting('app.active_user', true)
AND role = 'manager'
)
);
समस्याएं और उन्हें हल करने का तरीका
app.active_user के बजाय current_user का इस्तेमाल करना. | समस्या: Current_user, SQL का रिज़र्व किया गया कीवर्ड है. यह डेटाबेस की भूमिका (जैसे, app_user) दिखाता है. हमें ऐप्लिकेशन के उपयोगकर्ता (जैसे, ऐलिस).ठीक करें: हमेशा कस्टम नेमस्पेस का इस्तेमाल करें. जैसे, app.variable_name. |
| समस्या: अगर वैरिएबल सेट नहीं है, तो क्वेरी में गड़बड़ी होती है.हल: current_setting('...', true) फ़ंक्शन, गड़बड़ी होने के बजाय NULL दिखाता है. इससे सुरक्षित तरीके से 0 लाइनें मिलती हैं. |
7. "Chameleon" ऐप्लिकेशन बनाना
हम ऐप्लिकेशन लॉजिक को सिम्युलेट करने के लिए, Python और Streamlit का इस्तेमाल करेंगे.
एडिटर मोड में Cloud Shell टर्मिनल खोलें. इसके बाद, अपने रूट फ़ोल्डर या उस डायरेक्ट्री पर जाएं जहां आपको यह ऐप्लिकेशन बनाना है. नया फ़ोल्डर बनाएं.
1. Install Dependencies:
Cloud Shell टर्मिनल में, अपने नए प्रोजेक्ट की डायरेक्ट्री में जाकर यह कमांड चलाएं:
pip install streamlit psycopg2-binary
2. Create app.py:
app.py नाम की नई फ़ाइल बनाएं और repo फ़ाइल से कॉन्टेंट कॉपी करें.
import streamlit as st
import psycopg2
# CONFIGURATION (Replace with your IP)
DB_HOST = "10.x.x.x"
DB_NAME = "postgres"
DB_USER = "postgres"
DB_PASS = "alloydb"
def get_db_connection():
return psycopg2.connect(
host=DB_HOST, database=DB_NAME, user=DB_USER, password=DB_PASS
)
def query_database(user_name):
conn = get_db_connection()
try:
with conn.cursor() as cur:
# THE SECURITY HANDSHAKE
# We tell the database: "For this transaction, I am acting as..."
cur.execute(f"SET app.active_user = '{user_name}';")
# THE BLIND QUERY
# We ask for EVERYTHING. The database silently filters it.
cur.execute("SELECT name, role, salary, performance_review FROM employees;")
return cur.fetchall()
finally:
conn.close()
# UI
st.title("🛡️ The Private Vault")
user = st.sidebar.radio("Act as User:", ["Alice", "Bob", "Charlie", "Eve"])
if st.button("Access Data"):
results = query_database(user)
if not results:
st.error("🚫 Access Denied.")
else:
st.success(f"Viewing data as {user}")
for row in results:
st.write(row)
3. ऐप्लिकेशन चलाएं:
Cloud Shell टर्मिनल में, अपने नए प्रोजेक्ट की डायरेक्ट्री में जाकर यह कमांड चलाएं:
streamlit run app.py --server.port 8080 --server.enableCORS false
समस्याएं और उन्हें हल करने का तरीका
कनेक्शन पूलिंग. | जोखिम: कनेक्शन पूल का इस्तेमाल करने पर, सेशन वैरिएबल SET app.active_user, कनेक्शन पर बना रह सकता है. साथ ही, उस कनेक्शन का इस्तेमाल करने वाले अगले उपयोगकर्ता को "लीक" हो सकता है.ठीक करें:प्रोडक्शन में, कनेक्शन को पूल में वापस भेजते समय, हमेशा RESET app.active_user या DISCARD ALL का इस्तेमाल करें. |
Cloud Shell में खाली स्क्रीन दिख रही है. | ठीक करें: पोर्ट 8080 पर "वेब की झलक" बटन का इस्तेमाल करें. टर्मिनल में मौजूद लोकलहोस्ट लिंक पर क्लिक न करें. |
8. ज़ीरो ट्रस्ट की पुष्टि करना
ज़ीरो ट्रस्ट मॉडल लागू करने के लिए, ऐप्लिकेशन का इस्तेमाल करें:
"ऐलिस" को चुनें: उसे एक लाइन दिखनी चाहिए (खुद की).
"Bob" को चुनें: उसे तीन लाइनें दिखनी चाहिए (सभी लोग).
एआई एजेंट के लिए यह ज़रूरी क्यों है
मान लें कि आपको अपने मॉडल को इस डेटाबेस से कनेक्ट करना है. अगर कोई उपयोगकर्ता आपके मॉडल से यह सवाल पूछता है: "सभी परफ़ॉर्मेंस रिव्यू की खास जानकारी दो", तो यह SELECT performance_review FROM employees जनरेट करेगा.
- आरएलएस के बिना: आपका मॉडल, सभी लोगों की निजी समीक्षाएं वापस पाता है और उन्हें एलिस को लीक कर देता है.
- आरएलएस के साथ: आपका मॉडल ठीक उसी क्वेरी को चलाता है, लेकिन डेटाबेस सिर्फ़ एलिस की समीक्षा दिखाता है.
यह ज़ीरो-ट्रस्ट एआई है. आपको डेटा को फ़िल्टर करने के लिए मॉडल पर भरोसा नहीं है. इसलिए, डेटाबेस को इसे छिपाने के लिए मजबूर किया जाता है.
इसे प्रोडक्शन में ले जाना
यहां दिखाया गया आर्किटेक्चर, प्रोडक्शन-ग्रेड का है. हालांकि, इसे लागू करने के तरीके को सीखने के लिए आसान बनाया गया है. इसे किसी एंटरप्राइज़ के असली एनवायरमेंट में सुरक्षित तरीके से डिप्लॉय करने के लिए, आपको ये सुधार करने चाहिए:
- असली पुष्टि: "पहचान बदलने वाला" ड्रॉपडाउन को Google Identity Platform, Okta या Auth0 जैसे भरोसेमंद आइडेंटिटी प्रोवाइडर (आईडीपी) से बदलें. आपके ऐप्लिकेशन को डेटाबेस सेशन वैरिएबल सेट करने से पहले, उपयोगकर्ता के टोकन की पुष्टि करनी चाहिए और उसकी पहचान को सुरक्षित तरीके से निकालना चाहिए. इससे यह पक्का होता है कि उपयोगकर्ता अपनी पहचान को गलत तरीके से पेश न कर पाएं.
- कनेक्शन पूलिंग की सुरक्षा: कनेक्शन पूल का इस्तेमाल करते समय, सेशन वैरिएबल कभी-कभी अलग-अलग उपयोगकर्ता अनुरोधों के लिए बने रहते हैं. ऐसा तब होता है, जब उन्हें सही तरीके से मैनेज न किया जाए. पक्का करें कि आपका ऐप्लिकेशन, सेशन वैरिएबल को रीसेट करता हो. उदाहरण के लिए, RESET app.active_user) या कनेक्शन को पूल में वापस भेजते समय कनेक्शन की स्थिति को मिटा देता है, ताकि उपयोगकर्ताओं के बीच डेटा लीक न हो.
- सीक्रेट मैनेजमेंट: डेटाबेस क्रेडेंशियल को हार्डकोड करना, सुरक्षा के लिए जोखिम भरा होता है. डेटाबेस के पासवर्ड और कनेक्शन स्ट्रिंग को सुरक्षित तरीके से सेव करने और रनटाइम के दौरान उन्हें वापस पाने के लिए, Google Secret Manager जैसी सीक्रेट मैनेजमेंट सेवा का इस्तेमाल करें.
9. व्यवस्थित करें
इस लैब को पूरा करने के बाद, alloyDB क्लस्टर और इंस्टेंस को मिटाना न भूलें.
इससे क्लस्टर और उसके इंस्टेंस मिट जाएंगे.
10. बधाई हो
बधाई हो! आपने डेटा लेयर में सुरक्षा से जुड़ी सेटिंग को पुश कर दिया है. अगर आपके Python कोड में कोई ऐसी गड़बड़ी थी जिसकी वजह से print(all_salaries) की कोशिश की गई थी, तो भी डेटाबेस, ऐलिस को कोई जानकारी नहीं देगा.
अगले चरण
- अपने डेटासेट के साथ इसे आज़माएं.
- AlloyDB AI के दस्तावेज़ देखें.
- ज़्यादा वर्कशॉप के लिए, Code Vipassana की वेबसाइट देखें.