سجلات الاستعلام عن موارد Azure

في Azure Monitor Log Analytics يتم في العادة تنفيذ الاستعلامات في سياق مساحة العمل. قد تشتمل مساحة العمل على بيانات للعديد من الموارد، مما يجعل من الصعب عزل البيانات لمورد معين. إضافة إلى ذلك، قد ترسل الموارد بيانات إلى مساحات عمل متعددة. لتبسيط هذه التجربة، تسمح واجهة برمجة تطبيقات REST بالاستعلام عن موارد Azure بشكل مباشر لسجلاتها.

تنسيق الاستجابة

تنتج استعلامات موارد Azure نفس شكل الاستجابة كاستعلامات تستهدف مساحة عمل Log Analytics.

تنسيق عنوان URL

ضع بعين اعتبارك مورد Azure بمعرف مؤهل بالكامل:

/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>

سينتقل استعلام سجلات هذا المورد مقابل نقطة نهاية API المباشرة إلى عنوان URL التالي:

https://api.loganalytics.azure.com/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query

سيستخدم الاستعلام إلى نفس المورد من خلال ARM عنوان URL التالي:

https://management.azure.com/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/providers/microsoft.insights/logs?api-version=2018-03-01-preview

بشكل أساسي، فإن عنوان URL هذا هو مورد Azure المؤهل بالكامل بالإضافة إلى موفر الملحق: /providers/microsoft.insights/logs.

الوصول إلى الجدول والتحكم في الوصول استناداً إلى الدور

يعرض microsoft.insights موفر الموارد مجموعة جديدة من العمليات للتحكم في الوصول إلى السجلات على مستوى الجدول. تحتوي هذه العمليات على التنسيق الآتي لجدول يسمى tableName.

microsoft.insights/logs/<tableName>/read 

يمكن إضافة هذا الإذن إلى الأدوار باستخدام الخاصية actions للسماح للجداول المحددة والخاصية notActions عدم السماح بالجداول المحددة.

التحكم بالوصول إلى مساحة العمل

تبحث استعلامات موارد Azure على مساحات عمل Log Analytics كمصادر بيانات ممكنة. ومع ذلك، يمكن للمسؤولين تأمين الوصول إلى مساحة العمل عبر أدوار RBAC. افتراضيا، تقوم API بإرجاع النتائج فقط من مساحات العمل التي يملك المستخدم أذونات الوصول إليها.

يمكن لمسؤولي مساحة العمل استخدام استعلامات موارد Azure دون قطع التحكم في الوصول استنادا إلى الدور الموجود. تتيح الخاصية المنطقية في مساحة العمل للمستخدمين الذين لديهم سجلات عرض أذونات القراءة لمورد Azure معين ولكن ليس الاستعلام عن مساحة العمل التي تحتوي على تلك السجلات.

هذا هو الإجراء المتبع لتحديد نطاق الوصول إلى الجداول على مستوى مساحة العمل:

microsoft.operationalinsights/workspaces/query/<tableName>/read

استجابات الخطأ

فيما يلي قائمة موجزة بسيناريوهات الفشل الشائعة عند الاستعلام عن موارد Azure بالإضافة إلى وصف لسلوك الأعراض.

مورد Azure غير موجود

    HTTP/1.1 404 Not Found 
    { 
        "error": { 
            "message": "The resource /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/test-rg/providers/microsoft.storage/storageaccounts/exampleResource was not found", 
            "code": "ResourceNotFoundError" 
        }
    }
}

لا يمكن الوصول إلى المورد

HTTP/1.1 403 Forbidden 
{
    "error": { 
        "message": "The provided credentials have insufficient access to  perform the requested operation", 
        "code": "InsufficientAccessError", 
        "innererror": { 
            "code": "AuthorizationFailedError",
            "message": "User '92eba38a-70da-42b0-ab83-ffe82cce658f' does not have access to read logs for this resource"
        }
    } 
}

لا توجد سجلات من المورد، أو لا يوجد إذن لمساحة العمل المحتوية على تلك السجلات

اعتمادا على المجموعة الدقيقة من البيانات والأذونات، تحتوي الاستجابة إما على 200 بدون بيانات ناتجة، أو تطرح خطأ في بناء الجملة (خطأ 4xx).

وصول جزئي

توجد بعض السيناريوهات حيث يمكن أن يكون لدى المستخدم أذونات جزئية للوصول إلى سجلات مورد معين. هذه هي الحالة إذا كان المستخدم مفقودا إما:

• الوصول إلى مساحة العمل التي تحتوي على سجلات لمورد Azure.
• الوصول إلى مرجع الجداول في الاستعلام.

يرون استجابة عادية، مع مصادر البيانات التي لا يملك المستخدم أذونات للوصول إليها بصمت. للاطلاع على معلومات حول وصول المستخدم إلى مورد Azure، تتضمن مساحات عمل Log Analytics الأساسية، وإلى جداول معينة، العنوان Prefer: include-permissions=true مع الطلبات. يؤدي هذا إلى تضمين الاستجابة JSON مقطعا مثل المثال التالي:

{ 
    "permissions": { 
        "resources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM1", 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM2", 
                "denyTables": [ 
                    "SecurityEvent", 
                    "SecurityBaseline" 
                ], 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2",
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS3" 
                ] 
            } 
        ], 
        "dataSources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1", 
                "denyTables": [ 
                    "Tables.Custom" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2" 
            } 
        ] 
    } 
}

تصف حمولة resources محاولة الاستعلام عن جهازين ظاهريين. يرسل VM1 البيانات إلى مساحة العمل WS1، بينما يرسل VM2 البيانات إلى مساحتي عمل: WS2 وWS3. بالإضافة إلى ذلك، لا يملك المستخدم الإذن للاستعلام عن SecurityEvent الجداول أو SecurityBaseline للمورد.

تقوم حمولة dataSources بتصفية النتائج بشكل أكبر عبر وصف مساحات العمل التي يمكن للمستخدم الاستعلام بها. هنا، لا يملك المستخدم أذونات للاستعلام عن WS3، وجدول آخر تمت تصفيته من WS1.

لتوضيح البيانات التي سيعرضها مثل هذا الاستعلام:

• سجلات VM1 في WS1، باستثناء الجداول. مخصص من مساحة العمل.
• سجلات لأجل VM2، باستثناء SecurityEvent وSecurityBaseline، في WS2.