Hash-chained audit logs: वे क्या साबित करते हैं और क्या नहीं

Hash chain यह मजबूत प्रमाण दे सकती है कि audit records का कोई समूह चेन बनने के बाद edit, reorder या बीच में चुपचाप splice नहीं किया गया। लेकिन यह साबित नहीं करती कि application ने हर जरूरी event log किया, timestamp वास्तविक समय से मेल खाता है या नामित व्यक्ति ने कार्रवाई की। इन सभी बातों का प्रमाण मान लेना ऐसा evidence package बनाने का तरीका है जो पहली गंभीर पूछताछ में बिखर जाता है।

मैंने incident reviews को इसलिए रुकते देखा है क्योंकि लोगों ने log से ऐसे सवालों के जवाब मांगे जिनके लिए उसे बनाया ही नहीं गया था। चेन का verification सही निकला, फिर भी कोई यह तय नहीं कर सका कि service ने denied request log की थी या नहीं, operator की पहचान असली थी या नहीं, या system clock में कितना बदलाव आया था। Cryptography ठीक थी। Evidence package अधूरा था।

APIs और SSH तक पहुंच रखने वाले agents चलाने वाले developers के लिए यह फर्क और भी महत्वपूर्ण है। Agent बहुत कम समय में कई कार्रवाइयां कर सकता है। बाद में अक्सर सटीक सवाल उठता है: इस call का अनुरोध किस process ने किया, किस authority के तहत किया, executor ने ठीक कौन-सा request भेजा, क्या परिणाम आया और क्या किसी ने उसे approve किया? Hash chain इस कहानी के एक हिस्से की रक्षा करती है। बाकी हिस्सा आपको खुद दर्ज करना होगा।

Valid chain record continuity साबित करती है, reality नहीं

Valid hash chain यह साबित करती है कि उपलब्ध हर record पिछले record से commit करता है और चुने गए starting point के बाद sequence अंदरूनी रूप से consistent रही है। अगर कोई पुराने event को बदलता है, दो events की जगह बदलता है या दो मौजूदा records के बीच नया record डालता है, तो verification विफल हो जाएगा, जब तक कि वह बाद के हर link को फिर से न बनाए और हर trusted checkpoint को बदल न दे।

यह meaningful evidence है। इससे investigator कह सकता है, «ये records उसी sequence का हिस्सा हैं जिसने यह ज्ञात chain head बनाया था।» इस वाक्य में हर शब्द महत्वपूर्ण है। यह दावा किसी ज्ञात chain head या दूसरे trusted reference पर निर्भर करता है। अगर chain की अकेली copy और उसका final digest उसी मशीन पर हैं जिस पर हमलावर का नियंत्रण था, तो वह दोनों को बदल सकता है।

Hash chain इन दावों को साबित नहीं करती:

• Application ने हर उस event को देखा जिसे record किया जाना चाहिए था।
• Event payload logger के बाहर वास्तव में हुई घटना का सही वर्णन करता है।
• Event time किसी भरोसेमंद clock से मेल खाता है।
• कार्रवाई किसी व्यक्ति ने की, न कि उसके credential का इस्तेमाल कर रहे compromised process ने।
• Chain हमलावर के system पर नियंत्रण पाने से पहले शुरू हुई थी।

ये अलग-अलग propositions हैं और इनके लिए अलग-अलग evidence चाहिए। Log को «tamper proof» न कहें। SHA-256 इस्तेमाल करने से software को यह दर्जा नहीं मिल जाता। Chain तय assumptions के तहत बदलावों को detectable बनाती है। यही इसका उपयोगी और बचाव योग्य गुण है।

Integrity और completeness के बीच का फर्क खास ध्यान मांगता है। Integrity पूछती है कि आपके पास मौजूद records बदले गए हैं या नहीं। Completeness पूछती है कि कोई records गायब तो नहीं हैं। Chain पहले सवाल का अच्छा जवाब देती है। दूसरे सवाल का जवाब तभी देती है जब बाहरी evidence expected checkpoints और logger द्वारा emit किए जाने वाले events का scope दोनों तय करे।

Record format तय करता है कि hash वास्तव में किसकी रक्षा करता है

Chain केवल उन bytes की रक्षा करती है जो digest में जाते हैं। Algorithms पर बहस करने से पहले canonical event format तय करें और वे सभी fields शामिल करें जिनसे investigator को कार्रवाई समझने में मदद मिलेगी।

एक minimal record ऐसा दिख सकता है:

{
  "sequence": 1842,
  "event_id": "7b2ea6de-9c3f-4bb4-b1d7-8b13fbb1c5b9",
  "recorded_at": "2025-03-08T17:14:22.481Z",
  "actor": {"kind": "agent_process", "process_id": "p-91f"},
  "action": "http.request",
  "target": "api.example.internal/v1/releases",
  "request_digest": "sha256:...",
  "result": {"status": 201, "response_digest": "sha256:..."},
  "previous_hash": "sha256:..."
}

Writer record को एक तय रूप में serialize करता है, उन bytes को hash करता है और अगली record में बने digest को predecessor reference के रूप में रखता है। अवधारणा के स्तर पर:

record_hash[n] = SHA-256(canonical_record[n])
canonical_record[n+1].previous_hash = record_hash[n]

previous_hash field खुद उन bytes में होनी चाहिए जिनसे record_hash[n] बनता है। इसे छोड़ देना शर्मनाक लेकिन वास्तविक implementation mistake है। ऐसे design में records digest जैसे दिखने वाले decorations तो रखते हैं, लेकिन sequence को bind नहीं करते।

Canonicalization कोई छोटी तकनीकी बात नहीं है। दो JSON serializers object fields का क्रम अलग रख सकते हैं, Unicode को अलग तरह से escape कर सकते हैं या numbers को अलग format कर सकते हैं। Exact stored bytes को verify करने के बजाय JSON को फिर से बनाने वाला verifier सही records को reject कर सकता है या इससे भी खराब, record के अर्थ पर असहमति पैदा कर सकता है। Original byte representation सुरक्षित रखें, encoding तय करें और अलग-अलग implementations में verification की जांच करें।

Chain को केवल request body नहीं, context को भी cover करना चाहिए। «deployed» कहने वाला record कमजोर evidence है। ऐसा record जो executor version, action type, target identifier, authenticated process identity, authorization decision, request digest, response digest, sequence number और recorded time को bind करता है, reviewer को जांचने के लिए कुछ देता है। फिर भी यह साबित नहीं करता कि हर field सही है, लेकिन बाद में कोई editor कहानी को एक-एक field बदलकर नहीं लिख सकता।

NIST Special Publication 800-92, Guide to Computer Security Log Management, यही व्यावहारिक बात सरल operational भाषा में कहता है: analysis में मदद के लिए log records में event, source, user, status और timing की पर्याप्त जानकारी होनी चाहिए और organizations को log data की सुरक्षा करनी चाहिए। अस्पष्ट records के चारों ओर perfect chain लगाने से अस्पष्ट records ही पूरी तरह सुरक्षित होते हैं। यह audit design नहीं है।

पहला record और missing tail अब भी exposed रहते हैं

हर chain में एक पहला record होता है, जिसे अक्सर genesis record कहते हैं। उसका predecessor value convention से तय होता है, जैसे empty byte string का digest, या वह किसी पुराने checkpoint को reference करता है। Chain उसके बाद की continuity स्थापित कर सकती है। यह नहीं बता सकती कि history यहीं से क्यों शुरू होती है।

मान लें कोई service records 1 से 10,000 तक local storage में लिखती है। हमलावर को पूरा नियंत्रण मिलता है, वह records 1 से 7,000 हटा देता है, बचे हुए records में sequence field बदलता है और पुराने record 7,001 से शुरू होने वाली नई chain बनाता है। Forged chain verify हो जाती है। जिस reviewer के पास पहले का checkpoint नहीं है, उसे cryptographic defect दिखाई नहीं देगा।

Tail में भी यही समस्या होती है। Crash, power loss या हमलावर आखिरी कुछ events को durable storage तक पहुंचने से रोक सकता है। आखिरी बचा record सही तरह verify हो सकता है, भले ही कुछ क्षण बाद कोई action हुआ हो। Chain यह साबित करती है कि retained end बाद में बदला नहीं गया। यह नहीं साबित करती कि वही असली अंतिम event था।

इन दोनों gaps को कम करने के लिए writer के नियंत्रण से बाहर checkpoints जारी करें। Checkpoint में कम से कम chain identifier, sequence number, record hash और checkpoint time रखें। उसे अलग account, write-once store, external timestamping service या स्वतंत्र रूप से संचालित collector को भेजें। Signed checkpoint unsigned checkpoint से बेहतर है, क्योंकि वह statement को signing identity से जोड़ता है।

RFC 3161 एक time-stamp protocol बताता है जिसमें time-stamp authority इस evidence पर sign करती है कि उसने दिए गए समय पर message imprint देखा था। इससे एक सीमित लेकिन उपयोगी दावा किया जा सकता है: उस समय तक authority के पास यह digest था। यह नहीं बता सकता कि event payload सही था, submitted checkpoint से पहले events छोड़े गए थे या actor authorized था। इसे timing और existence evidence के लिए इस्तेमाल करें, operational records के विकल्प के रूप में नहीं।

Checkpoint frequency risk decision है। Frequent checkpoints उस अवधि को छोटा करते हैं जिसमें कोई unanchored tail हटा सकता है। साथ ही उन्हें रखने और मिलाने के लिए अधिक external records चाहिए होते हैं। यह दावा न करें कि hourly checkpoints minute-level incident reconstruction सुरक्षित रखते हैं। अपनी operating procedure में maximum unanchored interval साफ लिखें।

Hash timestamp को trusted time में नहीं बदलता

Log timestamp बताता है कि record बनाते समय logger की clock ने क्या कहा। सामान्य debugging के लिए यह पर्याप्त हो सकता है। Deadlines, trading windows, termination के बाद access या अलग-अलग machines पर events के क्रम से जुड़े सवालों के लिए यह कमजोर evidence है।

Administrator local clock बदल सकता है। Virtual machine stale time के साथ resume हो सकती है। Network time synchronization विफल हो सकता है। सही तरह synchronized host भी वह समय दर्ज करता है जब उसके application ने event लिखा, जो remote service द्वारा request पाने या change commit करने के समय से अलग हो सकता है।

जब फर्क महत्वपूर्ण हो, तो इन समयों को अलग रखें:

• observed_at: originating component ने event कब देखा।
• recorded_at: audit writer ने record कब बनाया।
• remote_at: remote system ने लौटाया हुआ समय, अगर वह system ऐसा समय देता है।
• checkpoint_at: independent witness ने chain head कब स्वीकार किया।

इन सबको एक सुविधाजनक timestamp field में न मिलाएं। हर समय का source और failure mode अलग है। इससे investigator झूठी precision पर निर्भर रहने के बजाय एक range के बारे में सोच सकता है।

अगर आपको time evidence चाहिए, तो दर्ज करें कि host time को कैसे synchronize करता है, synchronization health alerts सुरक्षित रखें और signed checkpoint receipts बचाकर रखें। High-consequence operations में local record की तुलना remote service के अपने audit entry से करें। 10:02:01 पर log हुई request और 10:02:05 पर remote system में log हुआ change एक ही action बता सकते हैं। Chain आपके record को editing से बचाती है, corroboration उसे external system से जोड़ती है।

एक आम सलाह है, «Append-only database और timestamps इस्तेमाल करें, फिर audit problem हल हो जाती है।» यह इसलिए लोकप्रिय है क्योंकि operational रूप से सरल लगता है। यह गलत है, क्योंकि एक service के भीतर append behavior clock trust, missing events, identity या बाहरी effects के बारे में बहुत कम बताता है। Append-only storage उपयुक्त हो तो इस्तेमाल करें, लेकिन साफ बताएं कि अब भी कौन-सा proof आपके पास नहीं है।

Attribution के लिए digest से बाहर identity trail चाहिए

Hash chain actor = [email protected] जैसे attribution claim को सुरक्षित रख सकती है। यह साबित नहीं कर सकती कि Alice ने credential दिया था, identity provider ने उसे सही तरह authenticate किया था या किसी हमलावर ने उसके active session का इस्तेमाल नहीं किया। Digest sentence की रक्षा करता है, उसकी सच्चाई की नहीं।

Agent actions के लिए vague user field से process identity अक्सर अधिक उपयोगी होती है। Agent process identifier, जहां उपलब्ध हो parent process, executable signing authority, launch time, session identifier और session को authorize करने वाले human या service account को दर्ज करें। केवल process name कमजोर evidence है। कोई भी program परिचित नाम चुन सकता है।

Code signing एक सीमित statement देती है: operating system यह पहचान सकता है कि executable पर किसी signing authority से जुड़ी signature है और platform के rules के अनुसार signature valid है। यह साबित नहीं करती कि executable चलाने वाले की मंशा अच्छी थी। लेकिन यह उसी filename वाले किसी भी binary और ज्ञात build के बीच फर्क करने में मदद करती है।

Authentication और authorization के लिए भी अलग records चाहिए। Authentication बताता है कि system ने कौन-सा credential या principal स्वीकार किया। Authorization बताता है कि उस समय system ने कार्रवाई की अनुमति क्यों दी। Approval dialog, role assignment, token scope या change ticket authorization evidence हो सकते हैं। Action record में उस decision का stable reference या digest रखें और मूल decision record को access controls के तहत सुरक्षित रखें।

Digital signatures इस layer को बेहतर बनाती हैं, अगर उनका सही इस्तेमाल हो। अगर audit writer periodic chain heads पर sign करता है, तो verifier जांच सकता है कि private key रखने वाले ने वे signatures बनाए थे। इससे unkeyed hash से आगे source claim मिलता है। फिर भी यह private-key custody, certificate status, rotation records और certificate subject को वास्तविक operational identity से जोड़ने पर निर्भर करता है।

यह सब एक user string में न छिपाएं। Incident के दौरान लोगों को अलग-अलग पहचानना पड़ता है: run को approve करने वाला human, action का अनुरोध करने वाला process, उसे execute करने वाली service और credential स्वीकार करने वाला authority। ये चार अलग actors हो सकते हैं।

Authorization evidence activity से अलग सवाल का जवाब देता है

Activity record पूछता है, «Executor ने क्या किया?» Authorization record पूछता है, «उसे ऐसा करने की अनुमति क्यों मिली?» Teams अक्सर दोनों को मिला देती हैं क्योंकि वे एक ही request के दौरान दिखाई देते हैं। इससे investigation कठिन होती है।

मान लें कोई agent SSH command का अनुरोध करता है। Executor requested host, command digest, result, process identity और time दर्ज करता है। अलग authorization layer यह दर्ज करती है कि नए process को approval मिला, किसने approve किया, approval में क्या शामिल था और वह कब समाप्त हुआ। अगर SSH command बाद में चलता है, तो activity event को लागू authorization record का reference देना चाहिए।

इस design से reviewer सही सवाल पूछ सकता है। क्या command जारी हुई? Activity record देखें। Session को अनुमति थी? Authorization record देखें। Approval screen पर सही identity दिखाई गई थी? UI और process identity records देखें। Remote host ने command execute की? उसके server logs या resulting state देखें।

Session के लिए एक approval और हर sensitive credential use के लिए approval, अलग तरह का evidence देते हैं। Session approval बताती है कि किसी व्यक्ति ने किसी process को उसके पूरे lifetime में चलने की अनुमति दी। Per-action approval किसी खास operation के करीब लिया गया संकीर्ण decision देती है। कोई भी तरीका अपने आप बेहतर नहीं है। चुनाव action frequency, consequence और इस बात पर निर्भर करता है कि human बार-बार आने वाले prompts का सही मूल्यांकन कर सकता है या नहीं।

Approval fatigue design failure है, approvals दर्ज करना बंद करने का कारण नहीं। अगर किसी व्यक्ति को सैकड़ों एक जैसे requests दिखें, तो उसके clicks पर विचारपूर्वक authorization का बहुत कम भरोसा किया जा सकता है। कम-risk काम को सीमित session decision के तहत समूहित करें, credentials या ऐसे actions के लिए repeated confirmation रखें जिनमें human target और consequence समझ सके, और scope को सरल भाषा में दर्ज करें।

Approval event अपने आप informed consent भी साबित नहीं करती। यह दिखाती है कि approval mechanism ने एक decision दर्ज किया। User को दिखाए गए process details, उस display और executing process के बीच binding और audit record, ये सब तय करते हैं कि बाद में उस decision को कितना महत्व दिया जा सकता है।

Completeness इस बात पर निर्भर करती है कि actions logger से कहां बाहर निकल सकते हैं

Agent के पास raw credentials होने के बाद केवल log file में hash chain जोड़कर agent actions का complete record नहीं बनाया जा सकता। Agent को API token या SSH private key मिलते ही वह किसी दूसरे client को call कर सकता है, secret copy कर सकता है या audited path के बाहर request कर सकता है। Chain उन requests को faithfully सुरक्षित रख सकती है जिन्हें उसने देखा, लेकिन जरूरी requests छूट सकती हैं।

Completeness action boundary पर नियंत्रण से शुरू होती है। Credential रखने वाला component खुद network request या SSH operation execute करे और result लौटाने से पहले decision और outcome log करे। Agent को secret नहीं, result मिलना चाहिए। इससे दावा «हमने agent से अपना काम log करने को कहा» से बदलकर «credential holder ने इस channel से हर use को देखा» हो जाता है।

फिर भी scope साफ लिखना जरूरी है। अगर developer वही credential terminal में भी इस्तेमाल कर सकता है, तो audit trail agent-mediated use को cover करती है, हर credential use को नहीं। अगर agent executor को bypass करने वाले दूसरे network path तक पहुंच सकता है, तो trail उस path को cover नहीं करती। Completeness claim में channel, principal और covered period का नाम होना चाहिए।

Sallyport अपने समर्थित HTTP और SSH channels के लिए इसी boundary का पालन करता है: encrypted vault API और SSH credentials को agent से दूर रखता है, जबकि app action execute करके उसे record करती है। इससे इसका audit trail agent-side activity log की तुलना में बड़ा scope देता है, लेकिन यह किसी unrelated credential path से की गई कार्रवाइयों के बारे में दावा नहीं करता।

एक उपयोगी failure test है कि agent से external effect तक जाने वाला हर रास्ता बनाएं। Direct HTTP clients, shell tools, tokens वाली local files, browser sessions, cloud metadata services, CI variables और SSH configuration शामिल करें। Logged executor से बाहर का हर रास्ता completeness claim का exception है। उसे बंद करें, अलग रखें या exception को ईमानदारी से दर्ज करें।

Confidentiality, access और retention के लिए अलग controls चाहिए

Hash chains अपने आप कुछ disclose नहीं करतीं, लेकिन audit records में ऐसी जानकारी हो सकती है जिसे आप सामान्य application log में नहीं रखना चाहेंगे। Request URLs customer identifiers दिखा सकते हैं। Command lines में secrets हो सकते हैं। Responses में personal data हो सकता है। ऐसी chain जो records को बदलना कठिन बनाती है, लापरवाही से हुए disclosure को वापस लेना भी कठिन बना सकती है।

Audit storage encrypt करें और पढ़ने का अधिकार सीमित रखें। जहां संभव हो, integrity verify करने की क्षमता को content decrypt करने की क्षमता से अलग रखें। Verifier encrypted record bytes पर hashes फिर से बनाकर predecessor references से तुलना कर सकता है, बिना protected payload देखे। इससे authorized investigator के archive खोलने से पहले reviewer sealed archive की integrity जांच सकता है।

Redaction record के chain में जाने से पहले करें। लिखने के बाद secret बदलने से bytes बदल जाएंगे और chain टूट जाएगी। इसके बजाय sensitive request body का digest, stable token reference, जहां उचित हो length information या यह structured statement दर्ज करें कि कोई field withheld है। Redaction rule लिखें। वरना एक जैसे दिखने वाले दो records अलग-अलग logic से redact किए गए हो सकते हैं।

Retention भी evidentiary value को प्रभावित करती है। अगर retention job पुराने records delete करती है, तो उसे अपना record बनाना चाहिए जिसमें deleted range, लागू retention rule, deletion time और deletion से पहले का final checkpoint हो। Checkpoint को अलग archive में रखें। Chain deleted material वापस नहीं ला सकती, लेकिन बचा हुआ evidence दिखा सकता है कि deletion तय process के तहत हुई, चुपचाप नहीं।

Access logging भी महत्वपूर्ण है। किसने audit archive export किया, किसने उसे decrypt किया और किसने retention configuration बदली, यह दर्ज करें। Incident के दौरान audit logs पर खास ध्यान दिया जाता है। Chain पुराने records को चुपचाप बदलने से बचाती है, लेकिन readers का बड़ा समूह फिर भी sensitive contents copy कर सकता है या operator पर future logging दबाने का दबाव डाल सकता है।

जरूरत पड़ने से पहले archive verify करें

Verification एक routine operation होनी चाहिए जिसका result सुरक्षित रखा जाए, न कि ऐसा command जिसे outage के दौरान पहली बार चलाया जाए। आपकी procedure में exact archive range, verifier version, expected checkpoint source, verification time, operator और outcome लिखे होने चाहिए।

Verifier को कम से कम चार failures पहचाननी चाहिए: malformed records, गलत predecessor reference, ऐसा record जिसका digest stored bytes से मेल नहीं खाता और computed head तथा expected checkpoint के बीच mismatch। इसका output सुरक्षित रखना आसान होना चाहिए। उदाहरण के लिए:

$ audit verify --archive agent-actions-2025-03-08.log --checkpoint checkpoints/2025-03-08.json
chain_id: agent-actions-prod-a
records_checked: 1842
first_sequence: 1
last_sequence: 1842
computed_head: sha256:4e7c...a912
checkpoint_head: sha256:4e7c...a912
result: VALID

VALID का मतलब है कि verifier ने supplied bytes की supplied checkpoint से जांच की। इसका मतलब «हर production action मौजूद है» या «events सच हैं» नहीं है। यह limitation procedure में सीधे लिखें। दबाव में green result पढ़ने वाले लोग वरना उसे उससे अधिक अर्थ दे देंगे जितना उसमें है।

Nonproduction archive में destructive cases की जांच करें। Record body में एक byte बदलें। दो records की जगह बदलें। बीच का record हटाएं। Checkpoint head बदलें। Tail truncate करें। Verifier को हर case reject करना चाहिए। इसका अपवाद expected final checkpoint के बिना सामान्य tail truncation हो सकता है, जहां वह valid prefix report करे। यह report सही है और आपको सही वजह से चिंतित करना चाहिए।

Sallyport sp audit verify के जरिए offline chain verification देता है और उसका verifier vault key के बिना encrypted audit chain की जांच कर सकता है। Exports के बाद यह check चलाएं और अलग session तथा activity views से इसका मिलान करने का अभ्यास करें, इससे पहले कि कोई investigation आपको ऐसा करने पर मजबूर करे।

Evidence package में ऐसे records चाहिए जो उपयोगी ढंग से अलग-अलग हों

Defensible investigation में अलग-अलग failure modes वाले कई records इस्तेमाल होते हैं। Independent sources के बीच agreement उस एक log से अधिक विश्वसनीय होता है जो अपनी ही assumptions को दोहराता है।

Sensitive agent action के लिए hash-chained activity record, session या approval record, authenticated process identity, relevant configuration version, external checkpoint receipt और target system का अपना record या observable result रखें। हर सामान्य request के लिए हर source जरूरी नहीं है। लेकिन गलती होने के consequence के अनुसार पर्याप्त evidence जरूर चाहिए।

कभी-कभी sources असहमत होंगे। Network delivery में समय लगने के कारण local activity record remote service के timestamp से पहले हो सकता है। Request में success response मिल सकता है, जबकि remote system बाद में operation rollback कर दे। Session record approval दिखा सकता है, जबकि action record में granted authority का कोई use न दिखे। इन differences की जांच करें, उन्हें छिपाकर एक जैसा न बनाएं।

ठीक-ठीक लिखें कि आपका system कौन से claims support कर सकता है। उदाहरण के लिए: «इस archive में checkpoint X तक executor records का unmodified sequence है।» फिर वे claims भी लिखें जिन्हें दूसरे records के बिना support नहीं किया जा सकता: «यह archive अकेले यह साबित नहीं करती कि direct credential use नहीं हुआ।» स्पष्ट सीमाएं मजबूत claims को विश्वसनीय बनाती हैं।

पहली व्यावहारिक कार्रवाई के रूप में कोई एक high-consequence agent operation चुनें और उसे शुरू से अंत तक reconstruct करें। Action boundary, execution से पहले लिखे fields, execution के बाद लिखे fields, approval evidence, checkpoint destination, remote corroboration और हर bypass route पहचानें। अगर किसी हिस्से के लिए किसी व्यक्ति की याद पर निर्भर रहना पड़ता है, तो आपके पास अभी audit trail नहीं है। आपके पास ऐसी कहानी है जो incident के सामने टिक नहीं सकती।