Lesson 124 — Advanced

Identity, Networking & Tenancy

Public API mein sab kuch ek key par tikta hai. Managed platform mein tumhare paas asli cloud controls hain — roles, network paths, tenant boundaries aur keys. Is lesson mein hum in controls ko mechanism samjhenge, taaki tumhara workload security review survive kare.

⏱ 20 min• Advanced• Platform Anatomy: Bedrock, Vertex AI & Azure AI Foundry

API keys ki jagah cloud identity

Kya hai?

Model invoke karne ki permission dene ka tarika — API key ki jagah cloud identity: AWS mein IAM role, GCP mein service account, Azure mein managed identity. Har request ek principal (app, job, user) se aati hai, jo cloud jaanta hai.

Kab kaam aata hai?

Jab app production mein jaaye — service-to-service auth, scheduled jobs, aur kabhi bhi jab key rotation ya audit trail chahiye. Dev laptop pe temporary key chalegi, production mein nahi.

Kahan milta hai?

Cloud IAM consoles mein, infrastructure-as-code mein, aur workload identity binding mein. Tumhara deployment har service ko ek identity deta hai — isi se model invoke hota hai.

Farq simple hai: API key "kya laaya hai" batata hai, cloud identity "kaun hai" batati hai. Identity ke saath har invoke audit log mein principal ke naam se recorded hota hai — key ke saath bas "ek key use hui". Regulated environments mein ye farq hi sab kuch hai.

Migration tip: Public API app ko cloud lekar jaate waqt sabse pehla kaam — hardcoded key hatao, workload identity lagaao (kubernetes pods ke liye workload identity binding, VMs ke liye instance profiles, serverless ke liye service accounts).

Least privilege — model access par bhi

{
  "Effect": "Allow",
  "Action": ["bedrock:InvokeModel"],
  "Resource": "arn:aws:bedrock:*::foundation-model/approved-model-*",
  "Condition": {
    "StringEquals": {"aws:RequestedRegion": "ap-south-1"}
  }
}
# Principle: app ko sirf wahi model, sirf wahi region, sirf wahi action.

Model-scoped permission: wildcard (sab models) ki jagah sirf approved models — naya risky model kisi aur team ke account mein ho toh tumhari app use kar hi nahi sakegi.
Region-scoped: allowed region se bahar invoke hi na ho — residency rule ek line mein enforce.
Action-scoped: invoke do, training ya fine-tuning mat do — har capability alag permission se aati hai.
Separation of duties: app ka role deploy karne wale role se alag. App kabhi khud ko naya permission na de sake.

Review rule: Har quarter ek baar roles audit karo — "kisne last 90 days mein is permission ko use kiya?" Unused permission hata do. Ye chhota ritual security review ka sabse aasaan score hai.

Audit — kisne kya invoke kiya

Har managed platform apne audit log likhta hai: kaunsa principal, kab, kis model ko, kya request. Ye log cloud ke central logging service mein jaate hain — jahan retention, query aur alerting tumhare control mein hoti hai.

Kyun matter karta hai: incident ke waqt sawaal yahi hota hai — "PII wala prompt kis service se gaya tha?" Audit trail ka jawab minute-level detail mein deta hai.
Correlation ID: har request mein apna request id bhejo — platform log aur tumhara app log aapas mein join honge.
Alerting: "ek principal ne 10 minute mein 500 baar invoke kiya" jaise patterns pe alert — runaway loop aur misuse dono isi se pakde jaate hain.
Log bhi data hai: request metadata log hota hai, aksar payload nahi — par payload logging option ON ho toh wo bhi retention ke under. Check kar lo.

Private connectivity — no public egress

Public path:  app  ──public internet──▶  model endpoint
Private path: app  ──private link──▶  platform endpoint (public internet kabhi nahi)

kya milta hai: traffic tumhare cloud ke andar rehta hai,
               DNS bhi private, "data kabhi internet pe nahi" claim mumkin
kya kharcha:   extra configuration, cross-region cost, thoda setup time

Mechanism: platform private endpoints expose karta hai — tumhara traffic cloud provider ke backbone par chalta hai, public internet par nahi.
Kya milta hai: data exfiltration ka rasta band, compliance questionnaire ka "how does data leave your network" wala jawab clean.
Kya kharcha hai: setup complexity, cross-region calls ka extra cost, aur debugging mein thoda extra hop.
Verify karo: bina verify kiye "private" sirf label hai — flow logs mein check karo ki request public interface par dikhi hi nahi.

Rule: Private connectivity optional lagti hai, par jab compliance team poochhti hai "data kabhi internet pe nahi gaya?" — tab wahi ek line ka proof banti hai. Pehle se plan karo, baad mein add karna mushkil hota hai.

Tenant isolation — shared platform par

SaaS product bana rahe ho jo kai customers (tenants) ko AI deta hai — toh sabse bada sawaal: ek tenant ka data doosre tak pahunchta hai? Platform shared infrastructure par chalta hai, isolation tumhari design hai.

isolation ladder (strong se simple):
1. alag account/project per tenant   -> puri boundary, sabse mehnga
2. ek account, per-tenant credentials aur scoped keys
3. ek shared store, per-tenant mandatory metadata filter

har level par: retrieval index, cache aur logs bhi tenant boundary ke andar honi chahiye

Retrieval boundary: vector store mein filter optional nahi — mandatory query filter, warna ek tenant ka doc doosre ka jawab ban jaayega.
Cache aur rate limits: shared cache per-tenant key se namespace karo; ek tenant ka burst doosre ko na roke.
Logs bhi tenant-scoped rakho: debugging mein PII leak ek common incident hota hai.
Test karo: har release pe ek negative test — tenant A ke credentials se tenant B ka data maango, error aana chahiye.

Sabse common leak: Vector store ka filter bhool jaana. Query seedha gaya, top-k mein kisi aur ke docs aa gaye. Fix: filter query ke andar mandatory banao, service layer mein manually add karne ki jagah nahi.

Encryption aur customer-managed keys

Platform data at rest encrypt karta hai — ye default hai, sawaal yeh nahi. Sawaal yeh hai: key kiski hai? Default keys platform ke hain; customer-managed keys (CMK) option mein key tumhara cloud account rakhta hai.

Default encryption: zero setup, platform ka key, sab encrypted — chhote teams ke liye kaafi.
CMK: key material tumhare account mein — compliance kehta hai "data destruction control client ke paas ho". Key revoke karo toh data unreadable — "delete" ka strong proof.
Cost: CMK thoda extra setup aur cost leta hai — requirement ho tabhi lagao, default posture ke liye nahi.
Encryption ≠ access control: encrypted data par galat principal access le toh kuch nahi badla. Identity pehle, encryption uske upar.

CMK kab: Regulated data, contractual "customer holds keys" clauses, ya deletion proof chahiye — tab CMK. Baaki jagah default encryption enough hai; har jagah CMK lagana operations ka bojh banta hai.

Exercise

Question: AWS mein app ke naam par bani, model invoke karne dene wali cloud identity ka object kya kehlata hai?

Question: Request public internet se na guzre — aisi private network path ko platform terminology mein kya kehte hain? (private endpoint / public dns)

Question: Data at rest ki key client ke account mein rakhi jaaye — us option ko ek shabd mein kya kehte hain?

Question: Shared vector store mein tenant isolation ka sabse pehla mandatory check kya hai — metadata filter ya chunk size?

Common mistakes

Sabko wildcard permission de dena: All models, all regions, all actions — audit mein sabse pehle yahi phata hai. Fix: model-scoped, region-scoped, action-scoped policy likho; naye model ke liye policy update ek conscious step ho.
Hardcoded API key production mein: Codebase aur config files mein key — leak ka sabse aam rasta. Fix: workload identity/service account se replace karo; key management sirf local dev ke liye.
Tenant filter ko optional rakhna: Retrieval filter developer ke upar chhod diya toh kabhi kabhi bhool jaayega — cross-tenant leak. Fix: service layer mein mandatory filter, har release pe negative test.
Private connectivity claim bina verify kiye: Docs padh kar "private hai" bol diya, flow logs kabhi nahi dekhe. Fix: ek baar traffic flow verify karo — kis interface se request nikli.

Desi example: Society ka gate — pass, guard aur flat keys

Society mein bhi wahi hota hai jo platform par — guard (identity check) bina andar nahi, har flat ko sirf apni key (least privilege), aur maintenance wale ko har flat ki chabi nahi hoti (separation of duties):

gate guard   -> principal check (role/service account)
visitor pass -> scoped permission (sirf approved models)
flat keys    -> tenant isolation (ek tenant, ek boundary)
society log  -> audit trail (kisne kab aaya)

Interview angle — yahan se sawaal aate hain

Q: API key ki jagah cloud identity ka fayda? — Principal-level audit, scoped permission, rotation ke bina key management.
Q: Least privilege model access kaise lagoge? — Model-scoped, region-scoped, action-scoped policy; wildcard kabhi nahi.
Q: Private connectivity kya kharidti hai, kya deti hai? — Data path cloud ke andar (compliance proof), par setup complexity aur cost badhti hai.
Q: Multi-tenant SaaS mein isolation kaise? — Account separation ya scoped credentials + mandatory retrieval filters + tenant-scoped cache aur logs.

Lesson complete?

Identity aur boundary ke controls clear. Agla lesson — Regions, Residency & Compliance — mein dekhenge model kis region mein available hota hai, data kahan rehna chahiye, aur retention terms kaise padhi jaati hain.