Data/Locales/checks/hi/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Azure AD Connect Sync खाता (MSOL_) लेखापरीक्षा", "status": "machine-draft" }, "description": { "value": "जब Azure AD Connect Express मोड में स्थापित होता है तो यह MSOL_<random-hex> नामक एक डोमेन खाता बनाता है और उसे डोमेन नेमिंग कॉन्टेक्स्ट पर Replicating Directory Changes + Replicating Directory Changes All प्रदान करता है, यानी DCSync अधिकार। खाता प्रभावी रूप से Tier-0 है परंतु यह डिफ़ॉल्ट रूप से default Users container में रहता है, इसकी 10-वर्षीय पासवर्ड समाप्ति होती है, और यह विशेषाधिकृत-समूह सूचीकरण उपकरणों में शायद ही कभी दिखता है क्योंकि यह अपनी शक्ति समूह सदस्यता के बजाय सीधे ACL के माध्यम से प्राप्त करता है। इस खाते का समझौता कार्यात्मक रूप से एक डोमेन अधिग्रहण है।", "status": "machine-draft" }, "recommendedValue": { "value": "सभी MSOL_ खाते सूचीबद्ध हों, पासवर्ड पिछले 180 दिनों के भीतर घुमाया गया हो, प्रतिबंधित लॉगिन अधिकारों वाली एक Tier-0 OU में रखे गए हों, और AAD Connect सर्वर स्वयं एक Tier-0 सिस्टम के रूप में हार्डन किया गया हो।", "status": "machine-draft" }, "remediationSteps": { "value": "MSOL_ खाता खोजें: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}। पुष्टि करें कि इसके पास DCSync अधिकार हैं: dsacls 'DC=domain,DC=com' | findstr MSOL_। इसे एक Tier-0 admin OU में स्थानांतरित करें। AAD Connect टूलिंग का उपयोग करके पासवर्ड घुमाएं (मानक टूलिंग के माध्यम से रीसेट न करें: AAD Connect सर्वर पर ADSync PowerShell मॉड्यूल में Add-ADSyncADDSConnectorAccount का उपयोग करें)। एक लॉगिन-प्रतिबंध GPO लागू करें ताकि खाता केवल AAD Connect सर्वर पर स्थानीय रूप से लॉगिन कर सके। AAD Connect होस्ट को Tier-0 मानें: सीमित करें कि कौन इसे RDP/admin कर सकता है।", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "विशेषाधिकृत समूहों में बैकअप सॉफ़्टवेयर सेवा खाते", "status": "machine-draft" }, "description": { "value": "बैकअप सॉफ़्टवेयर (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) आमतौर पर बहुत उच्च अनुमतियों वाले सेवा खाते की मांग करता है। प्रलेखन अक्सर सेटअप की सरलता के लिए Domain Admin का सुझाव देता है, और कई प्रशासक इसका अनुपालन करते हैं। एक बार जब कोई हमलावर बैकअप सर्वर से समझौता कर लेता है (एक बारंबार रैंसमवेयर आरंभिक-पहुंच वेक्टर), तो वह सेवा खाते के माध्यम से Domain Admin प्राप्त कर लेता है। यह 2023-2025 इंसीडेंट रिस्पॉन्स डेटा में #1 रैंसमवेयर वृद्धि पथ है।", "status": "machine-draft" }, "recommendedValue": { "value": "कोई बैकअप-सॉफ़्टवेयर सेवा खाता Domain Admins, Enterprise Admins, Schema Admins, या Backup Operators का सदस्य न हो। विक्रेता-प्रलेखित न्यूनतम-विशेषाधिकार खातों और पृथक बैकअप क्रेडेंशियल का उपयोग करें।", "status": "machine-draft" }, "remediationSteps": { "value": "उपयोग में बैकअप उत्पाद की पहचान करें और उसके न्यूनतम-विशेषाधिकार मार्गदर्शन का पालन करें (Veeam: केवल backup-server local admin + object read वाला AD खाता; Rubrik: क्लाउड-केवल भूमिका में समर्पित service principal; इत्यादि)। बैकअप खाते को Domain Admins से हटाएं। जहां समर्थित हो gMSA में स्थानांतरित करें। बैकअप सर्वर को प्रतिबंधित लॉगिन अधिकारों वाली एक Tier-1 OU में रखें। यदि किसी विशिष्ट कार्यभार के लिए वास्तव में पूर्ण DA आवश्यक है, तो इसे प्रलेखित करें और बैकअप के उस भाग को मुख्य खाते से अलग अपने स्वयं के खाते में पृथक करें।", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "विशेषाधिकृत समूहों में Hypervisor / वर्चुअलाइज़ेशन सेवा खाते", "status": "machine-draft" }, "description": { "value": "vCenter / Hyper-V / SCVMM / Citrix / Nutanix के AD के साथ एकीकरण अक्सर सेटअप के दौरान कॉन्फ़िगर किए गए सेवा खाते का उपयोग करते हैं। यदि वह खाता एक Domain Admin है, तो hypervisor प्रबंधन प्लेन (या होस्ट के SSO डेटाबेस) का समझौता AD तक कैस्केड हो जाता है। hypervisor वैचारिक रूप से पहले से ही Tier-0 है; इसकी AD पहचान भी वैसी ही होनी चाहिए।", "status": "machine-draft" }, "recommendedValue": { "value": "Hypervisor सेवा खातों के पास केवल विक्रेता द्वारा प्रलेखित अधिकार हों (आमतौर पर सूची के लिए read + यदि VM-AD एकीकरण उपयोग में है तो विशिष्ट OU writes)। Domain Admins में नहीं।", "status": "machine-draft" }, "remediationSteps": { "value": "प्रत्येक hypervisor उत्पाद के लिए AD सेवा खाते की समीक्षा करें। विक्रेता न्यूनतम-विशेषाधिकार मार्गदर्शन लागू करें। vCenter के लिए: किसी Domain Admin को मैप करने के बजाय प्रलेखित SSO identity source पैटर्न का उपयोग करें। Hyper-V/SCVMM के लिए: सेवा-खाता अधिकारों को VM कंप्यूटर खातों को होस्ट करने वाली OU तक सीमित करें। अपने प्रशासनिक मॉडल में hypervisor प्रबंधन होस्ट को Tier-0 मानें।", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "विशेषाधिकृत समूहों में Configuration Management सेवा खाते", "status": "machine-draft" }, "description": { "value": "Configuration-management प्लेटफ़ॉर्म (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) परिभाषा के अनुसार हर एंडपॉइंट पर सॉफ़्टवेयर पुश करते हैं: वे पहले से ही एक विशेषाधिकृत लेटरल-मूवमेंट प्लेटफ़ॉर्म हैं। विशेष रूप से SCCM के पास सुविख्यात दुरुपयोग प्रिमिटिव हैं (Network Access Account उजागरता, site server तक NTLM बाध्यता, client push)। Domain Admins में एक config-mgmt सेवा खाता किसी हमलावर को, जो किसी भी प्रबंधित एंडपॉइंट पर उतरता है, डोमेन की चाबियां दे देता है।", "status": "machine-draft" }, "recommendedValue": { "value": "Config-management सेवा खाते उनके प्रलेखित न्यूनतम अधिकारों तक सीमित हों और कभी Domain Admins / Enterprise Admins में न हों। SCCM Network Access Account एक गैर-विशेषाधिकृत समर्पित पहचान हो।", "status": "machine-draft" }, "remediationSteps": { "value": "config-mgmt उत्पाद की पहचान करें और सेवा खाता अधिकारों की समीक्षा करें। SCCM के लिए: सुनिश्चित करें कि Network Access Account गैर-विशेषाधिकृत है (Domain Admin नहीं); सुनिश्चित करें कि site server का मशीन खाता Domain Admin नहीं है; न्यूनतम विशेषाधिकार के लिए hierarchy सेवा खातों की समीक्षा करें। site servers और management points को प्रतिबंधित लॉगिन वाली एक Tier-0 OU में स्थानांतरित करें।", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "विशेषाधिकृत समूहों में SQL / डेटाबेस सेवा खाते", "status": "machine-draft" }, "description": { "value": "Domain Admins में SQL Server / MySQL / PostgreSQL सेवा खाते उन परिवेशों में सामान्य हैं जहां DBA टीम ने डिफ़ॉल्ट 'Use existing AD account' मार्गदर्शन के साथ SQL स्थापित किया और सुविधा के लिए एक admin खाता चुना। एक बार जब डेटाबेस सर्वर नेटवर्क पर पहुंच योग्य हो जाता है, तो एक SQL क्रेडेंशियल समझौता या एक SQL Server कमज़ोरी हमलावर को सीधे Domain Admin दे देती है।", "status": "machine-draft" }, "recommendedValue": { "value": "डेटाबेस सेवा खाते gMSA या समर्पित सेवा पहचानों के रूप में बिना किसी विशेषाधिकृत-समूह सदस्यता के चलें।", "status": "machine-draft" }, "remediationSteps": { "value": "जहां समर्थित हो SQL सेवा खातों को gMSA में स्थानांतरित करें। जिन खातों को उपयोगकर्ता-आधारित रहना ही है, उनके लिए विशेषाधिकृत समूह सदस्यता हटाएं और केवल वे स्थानीय अधिकार प्रदान करें जिनकी डेटाबेस इंजन को आवश्यकता है (Log on as a service, Bypass traverse checking, Adjust memory quotas for a process: विशिष्ट अधिकारों के लिए Microsoft दस्तावेज़ देखें)।", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "समर्पित Tier-0 OU के बाहर Tier-0 Admin खाते", "status": "machine-draft" }, "description": { "value": "यदि आपके Domain Admins सामान्य उपयोगकर्ताओं के समान OU में रहते हैं, तो उपयोगकर्ताओं को लक्षित करने वाला प्रत्येक GPO (लॉगिन स्क्रिप्ट, ब्राउज़र नीति, मैप की गई ड्राइव, इत्यादि) आपके Domain Admins पर भी लागू होता है, जिसका अर्थ है कि जो कोई भी उन GPO को संपादित कर सकता है, वह अगले लॉगिन पर Domain Admin के रूप में कोड चला सकता है। Microsoft श्रेणीबद्ध मॉडल प्रतिबंधित GPO लेखकत्व और प्रतिबंधित लॉगिन अधिकारों वाली एक समर्पित Tier-0 admin OU की अनुशंसा करता है।", "status": "machine-draft" }, "recommendedValue": { "value": "सभी Domain Admins, Enterprise Admins, और Schema Admins सदस्य प्रतिबंधित GPO लेखकत्व वाली एक समर्पित Tier-0 OU (आमतौर पर OU=Tier-0,OU=Admin) में हों।", "status": "machine-draft" }, "remediationSteps": { "value": "यदि OU=Tier-0,OU=Admin मौजूद नहीं है तो उसे बनाएं। Domain/Enterprise/Schema Admins के सभी सदस्यों को उसमें स्थानांतरित करें। उस OU पर GPO लेखकत्व प्रतिबंधित करें (केवल Tier-0 admins स्वयं)। एक समर्पित लॉगिन-प्रतिबंध GPO लागू करें ताकि Tier-0 खाते केवल Tier-0 होस्ट पर लॉगिन कर सकें। OU पर inheritance अवरुद्ध करें।", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "विशेषाधिकृत समूह के माध्यम से इंटरैक्टिव लॉगिन अधिकार वाले सेवा खाते", "status": "machine-draft" }, "description": { "value": "जो सेवा खाते Domain Admins (या डिफ़ॉल्ट विशेषाधिकृत-समूह सदस्यता के माध्यम से 'Allow log on locally' प्रदान किए गए किसी भी समूह) के सदस्य हैं, उन्हें इंटरैक्टिव रूप से उपयोग किया जा सकता है। हमलावर इसे पसंद करते हैं: किसी सेवा खाते का पासवर्ड कैप्चर करें (Kerberoasting, registry, SYSVOL में स्क्रिप्ट), उसे किसी वर्कस्टेशन पर इंटरैक्टिव रूप से उपयोग करें, LSASS डंप करें, और पिवट करें। सेवा खाते केवल उस होस्ट को छोड़कर, जिसकी वे सेवा करते हैं, किसी भी चीज़ पर इंटरैक्टिव रूप से लॉगिन नहीं कर पाने चाहिए।", "status": "machine-draft" }, "recommendedValue": { "value": "सेवा खाते (अनुमान: sAMAccountName svc/sa/service से शुरू होता है या इसमें SPN + हाल ही में कोई इंटरैक्टिव लॉगिन नहीं है) Default Domain Controllers Policy और एक समर्पित Tier-1/Tier-2 लॉगिन-प्रतिबंध GPO के माध्यम से स्पष्ट रूप से 'Allow log on locally' और 'Allow log on through Remote Desktop Services' से वंचित किए गए हों।", "status": "machine-draft" }, "remediationSteps": { "value": "सेवा खातों की पहचान करें (SPN-धारक, नामकरण परिपाटी, या व्यावसायिक सूची)। एक Default Domain Policy GPO लागू करें: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > 'Deny log on locally' = <service-accounts-group>। उन्हीं खातों को 'Deny log on through Remote Desktop Services' में जोड़ें। जहां समर्थित हो (Server 2012 R2+) उन्हें Protected Users में जोड़ें।", "status": "machine-draft" } } } |