Skip to main content
हर नीति का परीक्षण दो तरीकों से करें: आपके एजेंटों द्वारा पहले से तैयार किए गए ट्रैफ़िक के विरुद्ध, और एक वैध कार्रवाई के विरुद्ध जिसे इसे अनुमति देनी चाहिए। एक नीति जिसने केवल असुरक्षित मामले को देखा है, उसका परीक्षण नहीं किया गया है।

​
ड्राफ्ट का बैकटेस्ट करें

नीति संपादक एक ड्राफ्ट को उन कॉल के विरुद्ध फिर से चलाता है जो आपके फ्लीट ने पहले ही बना दिए हैं, इससे पहले कि आप इसे प्रकाशित करें।
  1. Admin → policy editor में ड्राफ्ट खोलें। संपादक पुष्टि करता है कि यह JavaScript के रूप में पार्स होता है।
  2. backtest में, उन एजेंटों और समय विंडो को चुनें जिन्हें आप फिर से चलाना चाहते हैं — डिफ़ॉल्ट रूप से every agent और 30d — और जब तक आप इसे सीमित नहीं करना चाहते, तब तक अंतिम फ़िल्टर को everything पर रखें।
  3. run backtest चुनें। एक ड्राफ्ट के अंतर्गत बैकटेस्ट पैनल जो JavaScript के रूप में पार्स होता है, इसके तीन फ़िल्टर और run backtest कार्रवाई के साथ, प्रकाशित संस्करण के ऊपर।
परिणाम वह है जो ड्राफ्ट उन कॉल के साथ करता — जिसमें वह कितनी working कॉल को बाधित करता, यह भी शामिल है। ये गलत सकारात्मक हैं जो किसी भी एजेंट से मिलने से पहले पाए जाते हैं: ड्राफ्ट को कसें और जब तक वह संख्या आपके लिए स्वीकार्य न हो, तब तक इसे फिर से चलाएं।

​
इसे किसी ऐसी घटना के विरुद्ध चलाएं जिसे आप वर्णित करते हैं

fp policies test नीति फ़ाइल को आपकी मशीन पर एक कृत्रिम घटना के विरुद्ध चलाता है और निर्णय की जांच करता है। कुछ भी प्रकाशित नहीं होता और कुछ भी Cloud तक नहीं पहुंचता:
--event, --tool, --command और --file के साथ घटना को आकार दें। नीति का अपना match फ़िल्टर अभी भी लागू होता है, इसलिए एक नीति जो आपके द्वारा वर्णित घटना को कवर नहीं करती है, एक निर्णय के बजाय skipped की रिपोर्ट करती है — आमतौर पर एक संकेत कि इसका match आपके इरादे से कम है।

​
इसे एक मशीन पर चलाएं

अगला, इसे अपनी मशीन पर वास्तविक रूप से लागू करें, अपने स्वयं के एजेंट के विरुद्ध:
पहली कमांड फ़ाइल को मान्य करती है और स्थापित करती है; दूसरी पुष्टि करती है कि यह लोड हो गई है, बाकी सब कुछ के साथ जो यहां लागू हो रहा है। एजेंट को वह करने के लिए कहें जो नीति रोकती है और देखें कि यह अस्वीकार कर दिया जाता है, फिर वैध संस्करण करें और देखें कि यह आगे बढ़ता है। कोई और प्रभावित नहीं है। Cloud से जुड़ी मशीन पर, Observe → policy के अंतर्गत दोनों निर्णयों की जांच करें: नीति के नाम से फ़िल्टर करें, फिर प्रत्येक लिंक किए गए सत्र को खोलें ताकि टूल इनपुट की पुष्टि कर सकें जो इसके साथ मेल खाता है और यह कारण कि इसने क्या लौटाया।

​
जो विफल हो उसका परीक्षण करें

स्थापना एक लापता फ़ाइल, एक सिंटैक्स त्रुटि, एक अनसुलझा आयात, एक शीर्ष-स्तरीय अपवाद, या एक मॉड्यूल जो लोडिंग के दौरान समय समाप्त हो जाता है, को अस्वीकार करता है — इसलिए फ़ाइल या इसमें शामिल किसी भी चीज में परिवर्तन के बाद इसे फिर से चलाएं। लागू समय पर वही टूटी हुई फ़ाइल लॉग की जाती है और skipped की जाती है ताकि हर दूसरी नीति चलती रहे: उत्पादन लॉग में एक लोड चेतावनी को खोई हुई लागू के रूप में मानें। कन्वेंशन फ़ाइलें स्थापना कमांड के बिना लोड होती हैं, इसलिए CI में एक स्पष्ट failproofai policies --install --custom <file> चरण रखें — यह वह है जो टूटी हुई नीति पर बिल्ड को विफल करता है। फिर इसे जो एजेंट वास्तव में भेजते हैं उससे खिलाएं, केवल वह इनपुट नहीं जिसकी आप अपेक्षा करते हैं: लापता फ़ील्ड, वैकल्पिक टूल नाम जैसे Write और Edit, Windows पथ, विकृत इनपुट। हर पथ पर एक इरादामय allow, instruct या deny लौटाएं, फ़ंक्शन को निर्धारक रखें, और किसी भी बाहरी कॉल को एक छोटे समय सीमा से बांधें।

​
फिर इसे प्रकाशित करें और इसे देखें

एक बैकटेस्ट दिखाता है कि नीति उस ट्रैफ़िक के साथ क्या करती: यह नहीं दिखा सकता कि आपने जो ट्रैफ़िक नहीं देखा है वह क्या करेगा। संपादक में publish version चुनें (या fp policies publish चलाएं), फिर इसे deploy it में observe मोड में पहले — इसके फैसले रिकॉर्ड किए जाते हैं और कुछ भी अवरुद्ध नहीं होता — और एक बार लागू करें जब इसके मेल असुरक्षित कार्यों को वैध कार्यों से अलग करते हैं।