---
title: लाइटवेट ज़ीरो ट्रस्ट ऑपरेशन्स मॉडल इम्प्लीमेंटेशन गाइड
description: "※यह लेख हमारी आंतरिक चर्चाओं, अनुभवों और सामान्य सुरक्षा सिद्धांतों के आधार पर संकलित है। यह किसी विशिष्ट कंपनी या संगठन के आधिकारिक विचार या किसी विशिष्ट वेंडर के आंतरिक कार्यान्वयन को नहीं दर्शाता है। --- ### ✅ अस्वीकरण -…"
url: "https://bestnetllc.co.jp/hi/docs/%e0%a4%b2%e0%a4%be%e0%a4%87%e0%a4%9f%e0%a4%b5%e0%a5%87%e0%a4%9f-%e0%a4%9c%e0%a4%bc%e0%a5%80%e0%a4%b0%e0%a5%8b-%e0%a4%9f%e0%a5%8d%e0%a4%b0%e0%a4%b8%e0%a5%8d%e0%a4%9f-%e0%a4%91%e0%a4%aa%e0%a4%b0/"
updated: "2026-10-19"
category: Tech Blog / AI सुरक्षा संचालन
---

# लाइटवेट ज़ीरो ट्रस्ट ऑपरेशन्स मॉडल इम्प्लीमेंटेशन गाइड

※यह लेख हमारी आंतरिक चर्चाओं, अनुभवों और सामान्य सुरक्षा सिद्धांतों के आधार पर संकलित है। यह किसी विशिष्ट कंपनी या संगठन के आधिकारिक विचार या किसी विशिष्ट वेंडर के आंतरिक कार्यान्वयन को नहीं दर्शाता है।

---

### ✅ अस्वीकरण

- इस लेख की सामग्री सूचना प्रणालियों के सामान्य डिज़ाइन और ऑपरेशन्स के दृष्टिकोण को प्रस्तुत करती है, और **सभी संगठनों के लिए सुरक्षा या अनुकूलता की गारंटी नहीं देती है**।
- वास्तविक कार्यान्वयन के लिए, **अपनी कंपनी के आकार, उद्योग, जोखिम सहनशीलता, कानूनी विनियमन और अनुबंध दायित्वों** को ध्यान में रखते हुए, विशेषज्ञ सलाह या आंतरिक समीक्षा करने की अनुशंसा की जाती है।
- इस लेख के आधार पर किए गए ऑपरेशन्स, कॉन्फ़िगरेशन, संगठनात्मक परिवर्तन आदि के कारण होने वाली किसी भी क्षति के लिए लेखक और संबद्ध संगठन किसी भी प्रकार की जिम्मेदारी नहीं लेते हैं।

---

## परिचय: एक व्यक्ति का "सब कुछ जानना" शक्तिशाली और खतरनाक है

इंफ्रास्ट्रक्चर, क्लाउड और सुरक्षा की दुनिया में,
"सब कुछ कर सकने वाले और सब कुछ जानने वाले 'देवता इंजीनियर'" को महत्व दिया जाता है।

हालांकि, साथ ही यह निम्नलिखित जोखिम भी उठाता है:

- यदि वह व्यक्ति चला जाए तो ऑपरेशन्स नहीं चल सकते (Bus Factor 1 है)
- अधिकार बहुत अधिक केंद्रित हो जाते हैं, जिससे गलत संचालन या घटना के समय प्रभाव घातक हो सकता है
- सुरक्षा की दृष्टि से भी "आंतरिक अपराध जोखिम" उच्च संरचना बन जाती है

बड़े पैमाने के क्लाउड, वित्तीय संस्थानों और SWIFT जैसी दुनिया में,
इस समस्या से बचने के लिए **"ऐसी संरचना जहां कोई भी संपूर्ण को नियंत्रित नहीं कर सकता"** सामान्य ज्ञान बनता जा रहा है।

हालांकि, यदि वही बात छोटे और मध्यम आकार के संगठनों में लागू करने की कोशिश की जाए,
**प्रबंधन लागत बहुत बढ़ जाती है** और फील्ड इसे संभाल नहीं सकता... यह भी एक वास्तविकता है।

इसलिए इस लेख में, हमने **छोटे से मध्यम आकार के संगठनों के लिए भी लागू करने में आसान "हल्का जीरो ट्रस्ट विभाजन मॉडल"** को व्यवस्थित किया है।

---

## मॉडल का लक्ष्य

इस मॉडल से हम निम्नलिखित स्थिति का लक्ष्य रखते हैं।

- ✅ एक व्यक्ति की "सब कुछ जानने और सब कुछ छूने" की स्थिति को समाप्त करना
- ✅ फिर भी दैनिक ऑपरेशन्स बहुत जटिल नहीं होते
- ✅ आपात स्थिति में ठीक से काम कर सकना (आपातकालीन प्रतिक्रिया भी विचार में)

"जीरो ट्रस्ट" सुनकर यह बड़ा लगता है,
लेकिन यहाँ **"लोगों और सिस्टम्स को केवल आवश्यक चीज़ों तक पहुँच देना"** जैसा विचार रखना ठीक है।

---

## चरण 1: भूमिकाओं को 3 भागों में विभाजित करें (डोमेन विभाजन)

सबसे पहले बहुत सरलता से,
**सिस्टम को 3 डोमेन में विभाजित करके विचार करें** यहाँ से शुरू करते हैं।

### A. इंफ्रा प्रभारी

- वर्चुअल प्लेटफॉर्म (VMware / Proxmox / Hyper-V आदि)
- OS (Linux / Windows)
- स्टोरेज
- बुनियादी नेटवर्क
- बैकअप प्लेटफॉर्म

### B. ऐप प्रभारी

- Web / API सर्वर
- मिडलवेयर (nginx / Apache / Redis / MQ आदि)
- डेटाबेस
- CI/CD पाइपलाइन
- एप्लिकेशन सेटिंग्स और डिप्लॉयमेंट

### C. सुरक्षा और प्रमाणीकरण प्रभारी

- IAM / खाता प्रबंधन
- VPN / SSO / AD / LDAP
- अनुमति डिज़ाइन
- प्रमाणपत्र और कुंजी प्रबंधन
- लॉग और ऑडिट बुनियादी ढांचा

**मुख्य बिंदु:**

> सुनिश्चित करें कि **एक ही व्यक्ति A + B + C सभी का पूर्ण अधिकार न रखे**।

छोटे संगठनों में भी,

- मुख्य प्रभारी + उप प्रभारी
- या "यहाँ तक एक्सेस है, लेकिन इससे आगे दूसरे व्यक्ति से अनुरोध करें"

इस सीमा को स्पष्ट रूप से परिभाषित करने मात्र से जोखिम काफी कम हो जाता है।

---

## चरण 2: अनुमति स्तर "केवल 3 स्तर" तैयार करें

ज़ीरो ट्रस्ट सुनते ही विस्तृत RBAC या रोल डिज़ाइन की छवि बनती है, लेकिन
छोटे परिवेशों में यह अत्यधिक जटिल हो सकता है और विफल हो सकता है।

इसलिए जानबूझकर **केवल 3 स्तरों** तक सीमित करें।

### D1. ऑपरेटर (संचालन ऑपरेटर)

- मॉनिटरिंग और लॉग देखना
- सेवाओं का रीस्टार्ट
- सरल कॉन्फ़िगरेशन परिवर्तन
- प्रक्रिया मैनुअल के अनुसार संचालन

### D2. रखरखाव व्यवस्थापक (इंफ्रा/एप्लिकेशन प्रबंधन)

- VM बनाना और हटाना
- स्टोरेज वॉल्यूम जोड़ना
- नेटवर्क सेटिंग परिवर्तन
- मिडलवेयर अपडेट और सेटिंग परिवर्तन

### D3. सुरक्षा व्यवस्थापक (IAM / प्रमाणीकरण)

- खाता बनाना और हटाना
- रोल और समूह परिभाषा परिवर्तन
- पासवर्ड नीति परिवर्तन
- VPN / कुंजी / प्रमाणपत्र का जीवनचक्र प्रबंधन

**पूर्ण नियम:**

> D2 (मेंटेनेंस एडमिनिस्ट्रेटर) और D3 (सिक्योरिटी एडमिनिस्ट्रेटर) को
> **एक ही व्यक्ति "हमेशा" दोनों भूमिकाओं में न रखें।**

यानी, "VM भी IAM भी सब कुछ कर सकने वाले सुपर एडमिनिस्ट्रेटर" को नियमित रूप से न रखें।

अगर संख्या की वजह से दोनों भूमिकाओं का एक व्यक्ति द्वारा निभाना जरूरी हो, तो

- आम तौर पर केवल एक को सक्रिय रखें
- दूसरे को आपातकालीन एस्केलेशन प्रक्रिया + लॉग के साथ अस्थायी उपयोग के लिए

इस तरह से करने की सिफारिश है।

---

## स्टेप 3: ऑपरेशन लॉग्स को "ठीक से रखना" ही काफी मजबूत है

भले ही परफेक्ट अनुमति डिज़ाइन न हो,
**"किसने कब क्या किया" को ट्रैक करना** ही रोकथाम और आश्वासन में बहुत फर्क लाता है।

### उदाहरण

- वर्चुअलाइजेशन प्लेटफॉर्म: ऑडिट लॉग (Proxmox / vCenter का Audit Log आदि)
- OS: `journalctl` / `auditd`
- नेटवर्क डिवाइस: syslog एकत्रीकरण
- IaC / Git: कमिट लॉग्स, Pull Request

**न्यूनतम आवश्यकता:**

1. महत्वपूर्ण कंपोनेंट्स के लिए**सभी में किसी न किसी रूप में लॉग आउटपुट** सक्षम करें
2. लॉग्स को संभव हो तो**एक जगह पर एकत्रित करें** (syslog सर्वर या लॉग इंफ्रास्ट्रक्चर)
3. "किसने, कब, किस खाता से, क्या किया" यह समझ में आने वाले रूप में रखें

> सिर्फ लॉग्स रखने से,
> "मनमानी करना मुश्किल वातावरण" स्वाभाविक रूप से बन जाता है।

---

## स्टेप 4: ऑटोमेशन, IaC से "लोगों के दिमाग" को सिस्टम में लाएं

व्यक्तिगत निर्भरता का मुख्य कारण है,

> **"सेटिंग्स और कॉन्फ़िगरेशन केवल उस व्यक्ति के दिमाग में हैं"**

यही है।

इसे तोड़ने का सबसे छोटा रास्ता, **ऑटोमेशन और IaC (Infrastructure as Code)** है।

### उदाहरण

- Terraform से क्लाउड/वर्चुअलाइजेशन प्लेटफॉर्म की कॉन्फ़िगरेशन प्रबंधन
- Ansible से OS / मिडलवेयर सेटिंग्स का मानकीकरण
- GitHub Actions / GitLab CI से डिप्लॉयमेंट का मानकीकरण
- शेल स्क्रिप्ट भी ठीक है, बस**मैनुअल काम को स्क्रिप्ट में बदलें**

मुख्य बात है,

> "लोगों द्वारा सीधे कंसोल छूने की संख्या को कम करना"

यह दिशा है।

---

## स्टेप 5: गुप्त जानकारी "लोगों" के बजाय "सिस्टम" को सौंपें

SSH प्राइवेट की, API की, पासवर्ड, प्रमाणपत्र—
इस तरह की जानकारी को **व्यक्तिगत लोकल PC या व्यक्तिगत प्रबंधन में न रखना** महत्वपूर्ण है।

### प्रमुख तरीके

- पासवर्ड मैनेजर (1Password, Bitwarden, KeePass आदि)
- Secrets प्रबंधन सेवाएँ (Vault, AWS Secrets Manager आदि)
- Git में सादे टेक्स्ट में न रखें (एन्क्रिप्ट करें / संदर्भ ID में बदलें)

"कौन किस सीक्रेट को एक्सेस कर सकता है" को सिस्टम साइड की अनुमतियों से नियंत्रित करके,
व्यक्ति से सीक्रेट को अलग रखने वाली संरचना का लक्ष्य रखें।

---

## स्टेप 6: डिज़ाइन दस्तावेज़ों को भी "विभाजित" करके रखें

दस्तावेज़ों को भी एक साथ रखने से,
केवल वही व्यक्ति मजबूत हो जाता है जो सब कुछ समझता है।

इसलिए, डिज़ाइन दस्तावेज़ों को भी भूमिकाओं के अनुसार विभाजित करें।

- नेटवर्क डिज़ाइन दस्तावेज़ (इंफ्रास्ट्रक्चर प्रभारी A द्वारा प्रबंधित)
- सर्वर संरचना और भूमिका सूची (इंफ्रास्ट्रक्चर / ऐप साझा)
- एप्लिकेशन संरचना दस्तावेज़ (ऐप प्रभारी B द्वारा प्रबंधित)
- प्रमाणीकरण और IAM डिज़ाइन दस्तावेज़ (सुरक्षा प्रभारी C द्वारा प्रबंधित)
- लॉग और ऑडिट डिज़ाइन दस्तावेज़ (सुरक्षा प्रभारी C)

> "एक व्यक्ति द्वारा लिखा गया और केवल उसी द्वारा समझा जाने वाला डिज़ाइन दस्तावेज़" की तुलना में,
> "कई लोगों द्वारा लिखा गया और भूमिकाओं के अनुसार विभाजित डिज़ाइन दस्तावेज़" अधिक स्वस्थ है।

---

## स्टेप 7: आपातकालीन स्थिति के लिए "दो-चरण मोड" तय करें

छोटे संगठनों को विशेष रूप से,
**"आपातकालीन स्थिति में कोई कुछ नहीं कर सकता और फंस जाता है"** पैटर्न से बचने की आवश्यकता है।

इसलिए, सामान्य समय और आपातकालीन समय के लिए नियमों को अलग करें।

### सामान्य समय

- अनुमतियों को D1 / D2 / D3 में विभाजित करके संचालित करें
- खतरनाक ऑपरेशन सिद्धांत रूप से केवल D3 द्वारा

### आपातकालीन समय

- उदाहरण के लिए "पूर्ण सेवा बंद", "गंभीर घटना" जैसी शर्तें तय करें
- लीडर + सुरक्षा प्रभारी आदि **2 या अधिक लोगों की सहमति से अस्थायी रूप से अनुमति बढ़ाएँ**
- रिकवरी के बाद अनुमति वापस करें और **ऑपरेशन लॉग की जाँच और समीक्षा करें**

ऐसा करने से,

> "सामान्यतः विभाजित रखें"
> "वास्तव में आवश्यक होने पर ही, ठीक से निशान छोड़ते हुए अस्थायी रूप से 'गॉड मोड' को अनुमति दें"

इस प्रकार का संतुलन बनाया जा सकता है।

---

## सारांश: "गॉड इंजीनियर अनावश्यक" आदर्शवाद नहीं, बल्कि डिज़ाइन का मुद्दा है

इस लेख में प्रस्तुत हल्के मॉडल को संक्षेप में कहें तो यह इस प्रकार है।

1. **इंफ्रास्ट्रक्चर / ऐप / सुरक्षा के 3 डोमेन में भूमिकाओं को विभाजित करें**
2. **अनुमतियों को 3 स्तरों (ऑपरेशन / प्रबंधन / सुरक्षा) में विभाजित करें, "हमेशा सब कुछ कर सकने वाले व्यक्ति" को समाप्त करें**
3. **ऑपरेशन लॉग ठीक से रखें, "किसने क्या किया" ट्रैक करने योग्य स्थिति बनाएं**
4. **इन्फ्रास्ट्रक्चर और सेटिंग्स को स्वचालित/IaC करें, "लोगों के दिमाग" को कोड में बदलें**
5. **गुप्त जानकारी लोगों के बजाय सिस्टम में रखें**
6. **डिज़ाइन दस्तावेज़ों को भी भूमिका के अनुसार विभाजित करके प्रबंधित करें**
7. **आपातकालीन स्थितियों में केवल "2 व्यक्तियों की अनुमोदन के साथ सुपर मोड खोलने" का नियम तय करें**

ये बड़े क्लाउड और वित्तीय संस्थानों, SWIFT आदि में उपयोग की जाने वाली अवधारणाओं को,
**छोटी से मध्यम आकार की कंपनियों में भी बिना कठिनाई के उपयोग करने योग्य बनाया गया मॉडल** है।

---

### अंत में

"एक व्यक्ति सब कुछ जानता है" की स्थिति,
अल्पावधि में बेहद सुविधाजनक है,
लेकिन दीर्घावधि में **व्यवसाय निरंतरता, सुरक्षा, और संगठनात्मक स्वास्थ्य** के दृष्टिकोण से बड़ा जोखिम बन जाती है।

इसके विपरीत,
**धीरे-धीरे "विभाजन", "पृथक्करण", "स्वचालन" को बढ़ाते जाएं तो,
"सुपर इंजीनियर पर निर्भर संगठन" से मुक्त हो सकते हैं**।

इस लेख की सामग्री केवल एक आधार है,
कृपया अपनी कंपनी की परिस्थितियों के अनुसार इसे अनुकूलित करें।