CloudTrail डेटा पर तालिकाएं बनाना

Athena कच्ची S3 फ़ाइलों पर तब तक क्वेरी नहीं चला सकता, जब तक आप उसे यह न बता दें कि उन्हें कैसे पढ़ना है। एक टेबल आपके S3 बकेट में मौजूद CloudTrail JSON फ़ाइलों को प्रकारों वाले नामित कॉलम से मैप करती है। टेबल बन जाने के बाद CloudTrail घटनाओं की समृद्ध संरचना साधारण SQL के माध्यम से उपयोग की जा सकती है।

CloudTrail घटनाओं को JSON के रूप में भेजता है। प्रत्येक रिकॉर्ड एक API कॉल का वर्णन करता है और उसमें userIdentity, eventName, sourceIPAddress और requestParameters जैसे नेस्टेड फ़ील्ड होते हैं। टेबल स्कीमा में इस नेस्टिंग की सही नकल होनी चाहिए, जिसमें ऑब्जेक्ट के लिए struct प्रकार भी शामिल हैं, ताकि क्वेरी userIdentity.arn जैसे फ़ील्ड तक पहुँच सके।

आपको स्कीमा हाथ से लिखने की आवश्यकता नहीं है। AWS CloudTrail के लिए एक मानक CREATE TABLE कथन प्रकाशित करता है और CloudTrail कंसोल तथा Athena इसे आपके लिए बना सकते हैं। उपलब्ध कराए गए DDL का उपयोग करने से प्रत्येक फ़ील्ड, यहाँ तक कि गहराई से नेस्ट किए गए फ़ील्ड भी, सही ढंग से मैप होते हैं और आपकी क्वेरी किसी डेटा को छोड़ती नहीं हैं।

SerDe (Serializer/Deserializer) Athena को बताता है कि हर फ़ाइल को कैसे पार्स करना है। CloudTrail तालिकाएँ CloudTrail के JSON लेआउट के लिए बनाए गए SerDe का उपयोग करती हैं, जो records ऐरे और नेस्टेड संरचनाओं को समझता है। सही SerDe चुनना आवश्यक है; गलत SerDe से पार्सिंग त्रुटियाँ या शून्य कॉलम मिलते हैं।

तालिका का LOCATION क्लॉज़ उस S3 प्रीफ़िक्स की ओर संकेत करता है जहाँ CloudTrail लॉग संग्रहीत करता है। आम तौर पर इस पथ में खाता ID और क्षेत्र शामिल होते हैं। इस प्रीफ़िक्स का सही होना महत्वपूर्ण है: बहुत व्यापक होने पर आप अप्रासंगिक डेटा स्कैन करेंगे, और बहुत संकीर्ण होने पर वे इवेंट छूट जाएँगे जिन्हें आप क्वेरी करना चाहते थे।

तालिका तैयार होने के बाद, आप डॉट नोटेशन का उपयोग करके नेस्टेड फ़ील्ड की क्वेरी करते हैं, जैसे userIdentity.arn या requestParameters.bucketName। SQL फ़ंक्शन ऐरे और JSON स्ट्रिंग को खोलने में सहायता करते हैं। जाँच-पड़ताल के लिए Athena की असली क्षमता यहाँ दिखाई देती है: आप किसी भी API कॉल के इवेंट नाम, प्रिंसिपल और पैरामीटर पर सटीक फ़िल्टर लगा सकते हैं।

मैन्युअल DDL के बजाय, AWS Glue crawler S3 डेटा को स्कैन करके Data Catalog में स्कीमा अपने-आप निर्धारित कर सकता है। CloudTrail जैसे प्रसिद्ध प्रारूपों के लिए दिया गया DDL आम तौर पर अधिक साफ़ होता है, लेकिन कस्टम या लगातार बदलते लॉग प्रारूपों में crawler उपयोगी होते हैं, जहाँ आप स्कीमा हाथ से नहीं लिखना चाहते।

CloudTrail JSON में कुछ फ़ील्ड स्वयं JSON स्ट्रिंग होते हैं, जैसे requestParameters, जब मान सेवा के अनुसार बदलते हैं। आप अक्सर क्वेरी के समय JSON फ़ंक्शन का उपयोग करके इन्हें पार्स करते हैं। यह समझना कि कुछ कॉलम पहले से संरचित कॉलम नहीं, बल्कि पार्स की जाने वाली स्ट्रिंग हैं, तब होने वाले भ्रम से बचाता है जब कोई फ़ील्ड सामान्य कॉलम की तरह व्यवहार नहीं करता।

किसी organization trail के लिए, सभी खातों के लॉग एक ही बकेट में खाता-विशिष्ट प्रीफ़िक्स के अंतर्गत आते हैं। आप पूरे प्रीफ़िक्स पर एक तालिका बनाकर एक साथ हर खाते की क्वेरी कर सकते हैं, या अलगाव के लिए प्रत्येक खाते की अलग तालिका बना सकते हैं। एकीकृत तालिका एक ही क्वेरी में पूरे संगठन के लिए खतरों की खोज करने में अत्यंत प्रभावी होती है।

तालिका बनाने के बाद, यह पुष्टि करने के लिए छोटे LIMIT के साथ एक त्वरित SELECT चलाएँ कि पंक्तियाँ लौट रही हैं और कॉलम अपेक्षा के अनुसार भर रहे हैं। यदि कॉलम शून्य हैं, तो SerDe, स्थान या स्कीमा में संभवतः गड़बड़ी है। यह प्रारंभिक जाँच आपको ऐसी तालिका के आधार पर जाँच-पड़ताल करने से बचाती है जो चुपचाप खराब हो गई हो।

CloudTrail तालिका सही हो जाने पर, आपके पास अब तक दर्ज पूरे इतिहास में फैला हुआ क्वेरी योग्य ऑडिट ट्रेल होता है। हर कंसोल लॉगिन, API कॉल और त्रुटि अब एक ऐसी पंक्ति है जिस पर आप फ़िल्टर और समुच्चयन कर सकते हैं। यह तालिका उन घटना-क्वेरियों की नींव है जिन्हें आप आगे लिखेंगे।

Athena में CloudTrail की क्वेरी करने के लिए आप एक table बनाते हैं, जो JSON फ़ाइलों को कॉलम से मैप करती है। इसके लिए AWS का दिया हुआ CREATE TABLE DDL, सही SerDe और सही S3 LOCATION उपयोग करें। nested fields की क्वेरी डॉट नोटेशन से करें, JSON-स्ट्रिंग कॉलम को क्वेरी के समय पार्स करें और छोटे SELECT से सत्यापन करें। किसी organization trail के लिए पूरे संगठन में खोज करने हेतु एक ही तालिका रखी जा सकती है।