1. खास जानकारी
GenAI ऐप्लिकेशन बनाने की जल्दबाज़ी में, हम अक्सर सबसे ज़रूरी कॉम्पोनेंट सुरक्षा को भूल जाते हैं.
मान लें कि आपको एचआर चैटबॉट बनाना है. आप चाहते हैं कि यह "मेरी सैलरी कितनी है?" या "मेरी टीम की परफ़ॉर्मेंस कैसी है?" जैसे सवालों के जवाब दे.
- अगर ऐलिस (एक सामान्य कर्मचारी) यह सवाल पूछती है, तो उसे सिर्फ़ अपना डेटा दिखना चाहिए.
- अगर बॉब (एक मैनेजर) यह सवाल पूछता है, तो उसे अपनी टीम का डेटा दिखना चाहिए.
समस्या
ज़्यादातर 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 Shell का इस्तेमाल करना होगा. यह Google Cloud में चलने वाला कमांड-लाइन एनवायरमेंट है. Google Cloud Console में सबसे ऊपर, Cloud Shell चालू करें पर क्लिक करें.
- Cloud Shell से कनेक्ट होने के बाद, यह देखने के लिए कि आपने पहले से ही पुष्टि कर ली है और प्रोजेक्ट को आपके प्रोजेक्ट आईडी पर सेट किया गया है, यह कमांड इस्तेमाल करें:
gcloud auth list
- Cloud Shell में यह कमांड चलाकर पुष्टि करें कि gcloud कमांड को आपके प्रोजेक्ट के बारे में पता है.
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 में लॉग इन करने के लिए, नीचे दिए गए बटन पर क्लिक करें या लिंक को अपने ब्राउज़र में कॉपी करें.
- यह चरण पूरा होने के बाद, रेपो को आपके लोकल क्लाउड शेल एडिटर में क्लोन कर दिया जाएगा. इसके बाद, प्रोजेक्ट फ़ोल्डर में जाकर, नीचे दिया गया कमांड चलाया जा सकेगा. यह पक्का करना ज़रूरी है कि आप प्रोजेक्ट डायरेक्ट्री में हों:
sh run.sh
- अब यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करें. इसके लिए, टर्मिनल में मौजूद लिंक पर क्लिक करें या टर्मिनल में "वेब पर झलक देखें" लिंक पर क्लिक करें.
- शुरू करने के लिए, प्रोजेक्ट आईडी, क्लस्टर, और इंस्टेंस के नाम की जानकारी डालें.
- जब लॉग स्क्रोल हो रहे हों, तब कॉफ़ी पिएं. साथ ही, यह भी देखें कि बैकग्राउंड में यह प्रोसेस कैसे हो रही है. इसमें करीब 10 से 15 मिनट लग सकते हैं.
अक्सर होने वाली समस्याएं और उनका हल
"इंतज़ार करने" की समस्या | डेटाबेस क्लस्टर, हैवी इन्फ़्रास्ट्रक्चर होते हैं. अगर आपने पेज को रीफ़्रेश किया या Cloud Shell सेशन को बंद कर दिया, क्योंकि वह "अटका हुआ दिख रहा था", तो हो सकता है कि आपको "घोस्ट" इंस्टेंस मिले. यह इंस्टेंस, आंशिक तौर पर सेट अप होता है और इसे मैन्युअल तरीके से बंद किए बिना मिटाया नहीं जा सकता. |
इलाके की समस्या | अगर आपने |
ज़ॉम्बी क्लस्टर | अगर आपने पहले किसी क्लस्टर के लिए वही नाम इस्तेमाल किया था और उसे मिटाया नहीं है, तो हो सकता है कि स्क्रिप्ट में यह मैसेज दिखे कि क्लस्टर का नाम पहले से मौजूद है. किसी प्रोजेक्ट में, हर क्लस्टर का नाम अलग-अलग होना चाहिए. |
Cloud Shell का टाइम आउट होना | अगर आपने 30 मिनट का ब्रेक लिया है, तो हो सकता है कि Cloud Shell स्लीप मोड में चला जाए और |
4. स्कीमा सेट अप करना
इस चरण में, हम इन विषयों के बारे में जानेंगे:
यहां चरण-दर-चरण पूरी प्रोसेस दी गई है:
AlloyDB क्लस्टर और इंस्टेंस चालू होने के बाद, एआई एक्सटेंशन चालू करने और स्कीमा सेट अप करने के लिए, AlloyDB Studio के एसक्यूएल एडिटर पर जाएं.
आपको इंस्टेंस के बनने तक इंतज़ार करना पड़ सकता है. इंस्टेंस बनने के बाद, क्लस्टर बनाते समय बनाए गए क्रेडेंशियल का इस्तेमाल करके, AlloyDB में साइन इन करें. PostgreSQL में पुष्टि करने के लिए, यह डेटा इस्तेमाल करें:
- उपयोगकर्ता नाम : "
postgres" - डेटाबेस : "
postgres" - पासवर्ड : "
alloydb" (या बनाते समय सेट किया गया कोई भी पासवर्ड)
AlloyDB Studio में पुष्टि करने के बाद, एसक्यूएल कमांड एडिटर में डाले जाते हैं. सबसे आखिरी विंडो के दाईं ओर मौजूद प्लस आइकॉन का इस्तेमाल करके, एडिटर की कई विंडो जोड़ी जा सकती हैं.
एडिटर विंडो में, 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, रिज़र्व किया गया एसक्यूएल कीवर्ड है. यह डेटाबेस रोल (जैसे, app_user) दिखाता है. हमें ऐप्लिकेशन उपयोगकर्ता (जैसे, ऐलिस) चाहिए.ठीक करें: हमेशा app.variable_name जैसे कस्टम नेमस्पेस का इस्तेमाल करें. |
| समस्या: अगर वैरिएबल सेट नहीं है, तो क्वेरी गड़बड़ी के साथ क्रैश हो जाती है.ठीक करें: current_setting('...', true) क्रैश होने के बजाय, NULL दिखाता है. इससे सुरक्षित तरीके से, कोई लाइन वापस नहीं मिलती. |
7. "गिरगिट" ऐप्लिकेशन बनाना
हम ऐप्लिकेशन लॉजिक को सिम्युलेट करने के लिए, Python और Streamlit का इस्तेमाल करेंगे.
एडिटर मोड में Cloud Shell टर्मिनल खोलें. इसके बाद, अपने रूट फ़ोल्डर या उस डायरेक्ट्री पर जाएं जहां आपको यह ऐप्लिकेशन बनाना है. नया फ़ोल्डर बनाएं.
1. डिपेंडेंसी इंस्टॉल करना:
Cloud Shell टर्मिनल में, अपने नए प्रोजेक्ट की डायरेक्ट्री में जाकर यह कमांड चलाएं:
pip install streamlit psycopg2-binary
2. app.py बनाना:
app.py नाम की नई फ़ाइल बनाएं और रेपो फ़ाइल से कॉन्टेंट कॉपी करें.
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 पर "वेब पर झलक देखें" बटन का इस्तेमाल करें. टर्मिनल में localhost लिंक पर क्लिक न करें. |
8. ज़ीरो ट्रस्ट की पुष्टि करना
ज़ीरो ट्रस्ट लागू करने की पुष्टि करने के लिए, ऐप्लिकेशन आज़माएं:
"ऐलिस" को चुनें: उसे एक लाइन (खुद की) दिखनी चाहिए.
"बॉब" को चुनें: उसे तीन लाइनें (सभी की) दिखनी चाहिए.
एआई एजेंट के लिए इसकी क्या अहमियत है
मान लें कि आपको अपने मॉडल को इस डेटाबेस से कनेक्ट करना है. अगर कोई उपयोगकर्ता आपके मॉडल से यह सवाल पूछता है: "सभी परफ़ॉर्मेंस की समीक्षाओं का सारांश दें", तो यह 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 की वेबसाइट देखें.