SaaS के लिए cloud audit logging और threat detection guide
Organization-wide event coverage, सुरक्षित central storage, तय retention, उपयोगी alerts और tested investigations के साथ SaaS cloud audit logging baseline बनाएँ।
इस मार्गदर्शिका में
Cloud audit logging में क्या capture होना चाहिए?
Cloud audit logging control-plane और चुनी हुई data-access activity record करती है ताकि team जाँच सके कि किसने resource, identity या policy बदली, कब बदली और क्या प्रभावित हुआ। यह application audit logs और operational metrics की पूरक है, उनका विकल्प नहीं। Accounts तथा projects map करें, जोखिम के अनुसार event categories चुनें, सुरक्षित central copies रखें और जाँचें कि responder असली incident सवालों का जवाब खोज सकता है।
Providers, environments और event categories की सूची बनाएँ
Cloud accounts, subscriptions, projects, regions, identity systems और critical services दर्ज करें। पहचानें कि कौन से provider logs हमेशा चालू हैं, कौन से data-access या resource logs को अलग से configure करना पड़ता है और क्या record नहीं होता। उदाहरण के लिए Google Cloud Admin Activity, Data Access, System Event और Policy Denied logs अलग करता है; कई services में Data Access logs default से बंद हैं और storage cost बढ़ा सकते हैं।
High-impact identity और configuration changes record करें
Authentication और privilege changes, नए credentials, public exposure, security-group या firewall edits, key-policy बदलाव, logging changes, नए resources और sensitive data पर administrative access को प्राथमिकता दें। Provider जो fields देता है उनमें stable actor, resource, time तथा result या denial reason होने की पुष्टि करें।
Cloud control-plane और product user activity अलग रखें
Cloud provider logs account या resource पर activity दिखाते हैं; वे हमेशा नहीं बताते कि SaaS user ने product के भीतर क्या किया। Tenant change, data export, role grant और account recovery जैसी application security events को application audit system में tenant scope तथा privacy controls के साथ record करें। Incident में दोनों को timestamp और request ID से जोड़ें।
| Account या project | Enabled events और gaps | Central destination और retention | Detection rule और test | Owner और evidence |
|---|---|---|---|---|
| Production identity और access | ||||
| Network और public exposure | ||||
| Sensitive data access |
Cloud audit logs को सुरक्षित और retained कैसे रखें?
महत्वपूर्ण records को अलग और restricted destination पर भेजें
जहाँ उचित हो, central security या log-archive account, project या subscription उपयोग करें। Logs बनाने की permission को उन्हें पढ़ने, retention बदलने या मिटाने की permission से अलग रखें। AWS CloudTrail के लिए dedicated central S3 destination सुझाता है; Google Cloud और Azure अपने organization-level routing तथा export विकल्प देते हैं।
Integrity controls चालू करें और collection रुकने पर alert पाएँ
जहाँ provider support करे वहाँ integrity validation या tamper-resistant storage सक्षम करें। Disabled trails, बदले हुए sinks, छूटे regions, export failures और अप्रत्याशित retention changes monitor करें। जो destination चुपचाप events लेना बंद कर दे, उससे वैसा ही investigation gap बनता है जैसे logging कभी enable ही न की गई हो।
Investigation और कानूनी जरूरत के अनुसार retention और cost तय करें
Incident response, contract और कानूनी जरूरतों के अनुसार searchable और archive अवधि चुनें; approver दर्ज करें। Azure activity logs default से 90 दिन रहती हैं, फिर अधिक समय के लिए export चाहिए; provider defaults अलग होते हैं, इसलिए वर्तमान limits जाँचें। Data-access logs अधिक मात्रा और खर्च बना सकते हैं; जरूरी services तथा events चुनें और destination का budget रखें।
Cloud audit logs से उपयोगी detections कैसे बनाएँ?
ऐसे risky changes पर alerts बनाएँ जिनकी जाँच हो सके
नया administrator, disabled logging, public database exposure, बदली हुई trust policy, unusual key use या अप्रत्याशित समय पर access जैसे events से शुरुआत करें। Alert में affected resource, actor, समय, बदलाव और response owner दें। ऐसी notifications से on-call team को न भरें जिनमें action या context न हो।
एक सुरक्षित, ज्ञात event से detections test करें
Controlled test event बनाएँ या खोजें, पुष्टि करें कि वह central destination तक पहुँचा, query और alert सही हैं, और on-call व्यक्ति supporting records खोल सकता है। Denied action के साथ successful change भी test करें। Expected delivery delay और signal न मिलने पर अगला कदम दर्ज करें।
Logs में personal और sensitive security data सुरक्षित रखें
Log access केवल जरूरत वाले लोगों तक सीमित रखें, जहाँ support हो redaction या field-level access लागू करें और investigation के स्पष्ट उद्देश्य बिना request bodies या secrets record न करें। Logs को sensitive data मानें, incident के दौरान सुरक्षित रखें और archive access की समीक्षा करें।
Cloud audit logging FAQs
क्या हर cloud action के लिए audit logs default से चालू हैं?
नहीं। Provider coverage और defaults service तथा event type के अनुसार बदलते हैं। कुछ control-plane logs हमेशा लिखे जाते हैं, जबकि data access के लिए अलग enablement और cost हो सकती है। Relevant services की सूची बनाएँ और असली records test करें; dashboard को पूरा इतिहास न मानें।
क्या cloud audit logs SaaS application audit logs के समान हैं?
नहीं। Cloud logs provider account या resource पर activity बताते हैं। Application audit logs में user द्वारा data export, tenant role change या account recovery जैसी product गतिविधियाँ होनी चाहिए। पूरी जाँच के लिए दोनों रखें और application में tenant access लागू करें।
SaaS company को cloud audit logs कितने समय रखने चाहिए?
हर service के लिए एक ही अवधि सही नहीं है। Incident investigation और लागू कानूनी या contractual दायित्व पूरे करने वाली documented अवधि चुनें; provider defaults, storage cost, deletion rules और archive से retrieval time verify करें। निर्णय और owner को review योग्य रखें।
क्या logs collect करने से attack अपने-आप detect हो जाता है?
नहीं। Collection evidence बनाती है; detection के लिए queries या rules, alert delivery, owner और अभ्यास की गई response प्रक्रिया चाहिए। Event creation से investigation तक पूरा रास्ता test करें, जिसमें missing या delayed logs भी हों।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .