عناصر التحكّم في خدمة سحابة VPC - الدرس التطبيقي حول الترميز لحماية BigQuery 1

1. مقدمة

في هذا الدرس التطبيقي، ستتعرّف على كيفية حماية واجهة BigQuery API باستخدام VPC Service Controls. يبدأ الدرس التطبيقي حول الترميز بدون خدمة واجهة برمجة تطبيقات محمية بمحيط الخدمة، ما يسمح بتشغيل طلبات البحث على مجموعات البيانات العامة، ويتم حفظ النتائج في جدول مشاريع. يتم تشغيل الاستعلام في مشروع واحد ويتم إنشاء الجدول (حيث يتم حفظ النتائج) في مشروع آخر، مما يحاكي إعدادًا حيث يمكن تخزين البيانات في مشروع واحد ولكن يجب الوصول إليها باستخدام مشروع مختلف.

بعد ذلك، سنقدم محيط خدمة لحماية مشروع البيانات. ستتعرَّف على كيفية إصلاح الانتهاكات المرصودة باستخدام قواعد الدخول وقواعد الخروج، ويمكنك لاحقًا إضافة مستوى وصول لتقييد الوصول باستخدام عناوين IP داخلية. تتمثل أهداف هذا الدرس التطبيقي حول الترميز في ما يلي:

• تعرَّف على كيفية إصلاح انتهاكات الدخول والخروج باستخدام قواعد الدخول والخروج على التوالي.
• فهم سبب حدوث انتهاك معين.
• تحليل نطاق إصلاح الانتهاكات المطبَّقة
• عدِّل الحل (قاعدة الدخول أو الخروج) لتغيير نطاقه من خلال الاستفادة من خيار السماح بالزيارات من عناوين IP الداخلية في شبكة VPC باستخدام مستويات الوصول.

2. إعداد الموارد والمتطلبات

قبل البدء

نفترض في هذا الدرس التطبيقي حول الترميز أنّك تعرف ما يلي:

• أساسيات تشغيل طلب بحث BigQuery: يمكنك الاطّلاع على هذا الدرس التطبيقي حول الترميز لمعرفة كيفية إجراء طلب بحث في مجموعة بيانات ويكيبيديا في BigQuery.
• كيفية إنشاء مجلد وإدارته
• كيفية إنشاء مشروع في مجلد أو نقل مشروع حالي في مجلد
• كيفية إنشاء سياسة وصول مُفصَّل
• كيفية إنشاء حيّز خدمة وضبطه
• كيفية العثور على انتهاكات سياسة الأمان في السجلّات

ضبط إعدادات الجهاز

تم تصميم الإعداد الأولي على النحو التالي:

إذا أكملت البرنامج التعليمي الأساسي لعناصر التحكّم في خدمة VC، يمكنك إعادة استخدام المشاريع والمجلد وحيِّ الخدمة نفسه.

• مؤسسة على Google Cloud:
• مجلد ضمن المؤسسة. في هذا الدرس التطبيقي حول الترميز، سنطلق عليه اسم codelab-folder.
• تم وضع مشروعَين على Google Cloud ضمن المجلد نفسه، codelab-folder. في هذا الدرس التطبيقي حول الترميز، نسميهما project-1 وproject-2
  • إذا لم يكن لديك المجلد والمشاريع التي سبق إنشاؤها، في Google Cloud Console، يمكنك إنشاء مجلد ضمن المؤسسة وإنشاء مشروعَين جديدَين ضمن ذلك المجلد الذي تم إنشاؤه.
• الأذونات المطلوبة:
  • أدوار إدارة الهوية وإمكانية الوصول لإدارة المجلدات: يتم تعيينها على مستوى المجلد
  • أدوار إدارة الهوية وإمكانية الوصول لإدارة المشاريع: يتم تعيينها على مستوى المشروع.
  • أدوار إدارة الهوية وإمكانية الوصول المطلوبة لضبط عناصر التحكّم في خدمة سحابة VPC: يتم تعيينها على مستوى المؤسسة
  • أدوار إدارة الهوية وإمكانية الوصول لإدارة BigQuery: يتم تعيينها على مستوى المشروع.
  • أدوار إدارة الهوية وإمكانية الوصول لإدارة مثيل Compute Engine: تم تعيينها على مستوى المشروع
• حساب فوترة لكلا المشروعَين: project-2 وproject-1

لأغراض هذا الدرس التطبيقي، يمكنك منح نفسك الأدوار التالية المحددة مسبقًا: مشرف المجلد ومنشئ المشروع (على مستوى المجلد) والمالك (على مستوى المشروع) ومشرف BigQuery (على مستوى المشروع) ومشرف مدير سياق الوصول (على مستوى المؤسسة). وستكون لديك الأدوار المطلوبة لإعداد الموارد اللازمة لهذا الدرس التطبيقي بأكمله.

إنشاء محيط خدمة منتظمة

في هذا الدرس التطبيقي حول الترميز، سنستخدم محيط خدمة عاديًا يحمي project-1.

• أنشئ محيطًا منتظمًا، وperimeter-1، وأضِف project-1.

لا تحظر أي خدمة في محيطك. سنفعل ذلك لاحقًا.

إنشاء جهاز افتراضي في Compute Engine

في هذا الدرس التطبيقي حول الترميز، سنستخدم مثيلاً واحدًا من Compute Engine في project-2، ويقع في us-central1 وباستخدام شبكة VPC تلقائية باسم default.

• يمكنك الرجوع إلى المستندات كدليل إرشادي لإنشاء مثيل في Compute Engine من صورة علنية.

في هذا الدرس التطبيقي حول الترميز، سنستخدم شبكة VPC التلقائية المسماة default. يمكنك أيضًا استخدام أي شبكة أخرى شرط أن تتضمّن الشبكة شبكة فرعية واحدة على الأقل.

التكلفة

عليك تفعيل الفوترة في Google Cloud Console لاستخدام الموارد/واجهات برمجة التطبيقات في السحابة الإلكترونية. ننصحك بإيقاف الموارد المستخدمة لتجنُّب تحمُّل الفوترة خارج نطاق هذا الدرس التطبيقي حول الترميز. يكون مستخدمو Google Cloud الجدد مؤهَّلون للانضمام إلى الفترة التجريبية المجانية التي تبلغ تكلفتها 300 دولار أمريكي.

الموارد التي تتكبّد تكلفة هي مثيل BigQuery وCompute Engine. يمكنك تقدير التكلفة باستخدام حاسبة الأسعار في BigQuery وحاسبة أسعار Compute Engine.

3- الوصول إلى BigQuery بدون قيود عناصر التحكّم في خدمة سحابة VPC

طلب مجموعة بيانات عامة وحفظ النتائج في project-1

1. يمكنك الوصول إلى project-2 وproject-1 للتأكّد من إمكانية الوصول إلى BigQuery API من خلال الانتقال إلى صفحة BigQuery Studio. من المفترض أن تتمكّن من إجراء ذلك لأنّه حتى إذا كان project-1 يقع في محيط الخدمة، فإنّ المحيط لا يحمي أي خدمة بعد.
2. من project-2، قم بتشغيل الاستعلام التالي للاستعلام عن مجموعة بيانات عامة.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

بعد تشغيل الطلب على مجموعة البيانات العامة (بينما تبقى في project-2):

1. انقر على حفظ النتائج واختر جدول BigQuery. (يُرجى الاطّلاع على لقطة الشاشة أدناه).
2. اختَر project-1 كمشروع الوجهة.
3. أدخِل اسمًا لمجموعة البيانات باسم codelab_dataset. (اختَر CREATE NEW DATASET (إنشاء مجموعة بيانات جديدة)، ما لم تستخدِم مجموعة بيانات حالية)
4. أدخِل اسمًا للجدول: codelab-table.
5. انقر على حفظ.

تم تخزين بيانات مجموعة البيانات العلنية بنجاح في project-1 نتيجة تنفيذ الطلب من project-2.

تم حفظ مجموعة بيانات الطلب في project-1 من project-2.

أثناء البقاء في project-2 BigQuery Studio، شغِّل طلب البحث التالي لاختيار البيانات من:

• المشروع: project-1
• مجموعة البيانات: codelab_dataset
• الجدول: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

يجب تنفيذ الطلب بنجاح، لأنّه لم يتم حصر استخدام BigQuery على project-2 أو project-1. يُسمح بالوصول إلى BigQuery من وإلى أي مكان طالما أنّ المستخدم لديه أذونات "إدارة الهوية وإمكانية الوصول" المناسبة.

يوضّح هذا المخطّط البياني العملية التي يتم فيها طلب عنصر رئيسي من مجموعة بيانات BigQuery. يؤدي كل استعلام في BigQuery إلى بدء مهمة BigQuery، التي تقوم بعد ذلك بتنفيذ العملية الفعلية، في هذا السيناريو، وهي استرداد البيانات. يتم توضيح إذن الوصول الرئيسي من خلال مثيل Compute Engine ومن الإنترنت، أثناء إجراء طلبات البحث من مجموعة بيانات عامة ومن مشروع منفصل على Google Cloud. تمت عملية طلب البيانات (GetData) بنجاح، بدون حظرها بواسطة عناصر التحكّم في خدمة "سحابة VPC".

4. حماية BigQuery API في مشروع مجموعة بيانات المصدر

عدِّل إعدادات المحيط perimeter-1 وفرض قيود على خدمة BigQuery API، فضلاً عن المورد المحمي الذي يكون project-1.

التحقق من فرض محيط الخدمة

من project-2، نفِّذ الاستعلام التالي في BigQuery Studio، كما في الخطوة السابقة:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

سيحدث انتهاك لعناصر التحكّم في خدمة سحابة VPC RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER

يمكنك العثور على سجلّ التدقيق في الانتهاك في project-1، لأنّ هذا هو المكان الذي وقعت فيه الانتهاك خارج الحدود. يمكن فلترة السجلّات باستخدام vpcServiceControlsUniqueId المرصود (استبدِل VPC_SC_DENIAL_UNIQUE_ID بالمعرّف الفريد المرصود).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

الانتهاك هو egressViolations مع:

• principalEmail: [حساب مستخدم ينفّذ طلب البحث]
• callerIp: [عنوان IP لوكيل المستخدم الذي يُجري طلب البحث]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5- إصلاح الانتهاك لإنشاء مهمة BigQuery

يشير انتهاك عناصر التحكّم في خدمة سحابة VPC إلى bigquery.jobs.create كإذن مستهدف بسبب طريقة عمل BigQuery. عند استخدام وحدة تحكُّم Google Cloud (أو أداة سطر الأوامر bq) لإدارة بيانات BigQuery، تُنشئ أداة BigQuery مهامًا يتم استخدامها بعد ذلك لإكمال الإجراءات المطلوبة. في الوقت نفسه، الحدث الأول هو إنشاء مهمة BigQuery.

يوضّح هذا المخطّط البياني الحالات التي ينفِّذ فيها العنصر الأساسي طلبًا من project-2 لمجموعة بيانات في project-1. إنّ عملية إنشاء مهمة BigQuery من مشروع مجموعة البيانات (project-1) في المشروع الذي يتم تنفيذ الطلب منه (project-2) يتعذّر استخدامها بسبب انتهاك سياسة خروج عناصر التحكّم في خدمة VPC بسبب محيط الخدمة perimeter-1 الذي يحمي BigQuery API. مع وجود المحيط، لا يمكن بدء طلب BigQuery API من project-1 باتجاه خارج المحيط أو بدؤه خارج المحيط نحو المشروع المحمي. ما لم تسمح إعدادات محيط الخدمة بذلك.

يمكن إصلاح انتهاك الخروج من خلال إنشاء قاعدة خروج تستند إلى:

• المصدر (FROM): وهو عنوان البريد الإلكتروني للمستخدم وسياقه (مثل عنوان IP للمتصل، وحالة الجهاز، والموقع الجغرافي، وما إلى ذلك)
• الوجهة (TO): أي المورد المستهدف والخدمة والطريقة أو الإذن.

لإصلاح الانتهاك الذي تم رصده بخصوص الخروج المرصود، يمكنك إنشاء قاعدة خروج تسمح بالزيارات إلى targetResource (project-2) من خلال حساب المستخدم الذي ينفِّذ الطلب ([e-mail]) على خدمة BigQuery وطريقة/ إذن bigquery.jobs.create.

السلوك المتوقّع من قاعدة الخروج التي تم ضبطها:

• FROM | الهويات: يجب السماح فقط للهوية المحدّدة [e-mail] باجتياز الحدود الجغرافية.
• إلى | مشروعات: لا يمكن للهوية المحددة تجاوز الحدود المحيطة إلا إذا كانت الوجهة هي المشروع المحدد project-2.
• إلى | الخدمات: لا يمكن للهوية المحددة بدء حركة مرور البيانات من المحيط إلى المشروع المحدد إلا إذا كان طلب بيانات من واجهة برمجة التطبيقات يتعلق بالخدمة والطريقة المحددتين. بخلاف ذلك، على سبيل المثال، إذا جرب المستخدم خدمة مختلفة محمية بمحيط الخدمة، سيتم حظر العملية بسبب عدم السماح بالخدمات الأخرى.

اختبار الإصلاح: قاعدة الخروج

بمجرد وضع قاعدة الخروج، قم بتشغيل نفس الاستعلام.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

ستحدث مخالفة أخرى، ولكن هذه المرّة، تشكّل انتهاكًا لسياسة NO_MATCHING_ACCESS_LEVEL. يختلف الانتهاك الجديد عن الانتهاك الأول، من حيث المشروع المستهدف والطريقة.

إنّ إصلاح انتهاك واحد لعناصر التحكّم في خدمة سحابة VPC لا يعني حدوث أي انتهاكات أخرى. سيؤدي طلب بيانات جديد من واجهة برمجة التطبيقات مع سياق مختلف عن السياقات التي تسمح بها السياسة التي سبق ضبطها إلى حدوث انتهاك مختلف.

الانتهاك الجديد هو انتهاك قيد التقدم مع

• principalEmail: [حساب مستخدم ينفّذ طلب البحث]
• callerIp: [عنوان IP لوكيل المستخدم الذي يُجري طلب البحث]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

يرجع سبب انتهاك طريقة bigquery.tables.getData إلى أنّ طلب البيانات من واجهة برمجة التطبيقات بدأه مهمة BigQuery في محاولة الحصول على البيانات من جدول BigQuery.

من المهم فهم آلية عمل خدمة واجهة برمجة التطبيقات (API) محددة لتوقع الانتهاكات المتوقعة.

6- إصلاح الانتهاك للحصول على بيانات جدول BigQuery

تعمل قاعدة الدخول على إصلاح انتهاك الدخول، مع توفير تحكُّم دقيق في تحديد المستخدمين المسموح لهم بعبور حدود الخدمة إلى جانب سياق الوصول المسموح به، مثل المشروع المصدر/ الهدف وطريقة واجهة برمجة التطبيقات التي يمكنه الوصول إليها.

يتم إصلاح انتهاك الدخول بواسطة قاعدة دخول تم ضبطها مع:

• المصدر (FROM): وهو عنوان البريد الإلكتروني للمستخدم وسياقه (مثل عنوان IP للمتصل، وحالة الجهاز، والموقع الجغرافي، وما إلى ذلك)
• الوجهة (TO): أي المورد المستهدف والخدمة والطريقة أو الإذن.

ستسمح قاعدة الدخول بالزيارات إلى project-1 من خلال المستخدم المحدّد على الخدمة والطريقة المحددة.

السلوك المتوقّع من قاعدة الدخول التي تم ضبطها:

• FROM | الهويات: يجب السماح فقط للهوية المحدّدة [e-mail] باجتياز الحدود الجغرافية.
• إلى | مشروعات: لا يمكن للهوية المحددة عبور الحدود إلا إذا كانت الوجهة هي المشروع المحدد project-1.
• إلى | الخدمات: لا يمكن للهوية المحدّدة بدء الزيارات داخل المحيط إلا إذا كان طلب بيانات من واجهة برمجة التطبيقات يخص BigQuery API والطريقة المحدّدة bigquery.tables.getData.

من المفترض أن يبدأ تنفيذ طلب البحث نفسه بشكل سليم بدون انتهاك عناصر التحكّم في خدمة سحابة VPC.

لقد نجحنا في فرض قيود على BigQuery API في project-1 بحيث يمكن استخدامها فقط بواسطة [e-mail] وليس بحلول [e-mail].

يوضّح هذا المخطّط البياني كيف يحاول كيانان مختلفان طلب البحث في مجموعة البيانات نفسها. رفضت عناصر التحكّم في خدمة سحابة VPC وصول [e-mail] (الخطوط الزرقاء المنقطة) لأنّه لا يُسمح لها بتشغيل عمليات BigQuery من project-1 أو تجاهها من خلال إعدادات محيط الخدمة. تم بنجاح الوصول إلى البيانات من خلال "[e-mail]" (الخط المتصل الأخضر)، لأنّها تسمح بها إعدادات عناصر التحكّم في خدمة "سحابة VPC" بإجراء العمليات من project-1 وإليه.

7. تقييد الزيارات المسموح بها من خلال محيط الخدمة استنادًا إلى عنوان IP الداخلي

تتيح الإعدادات الحالية للمستخدم المحدّد تنفيذ طلبات على BigQuery في "project-1" من أي موقع. في أي مكان على الإنترنت، إذا تم منحهم إذن "إدارة الهوية وإمكانية الوصول" لطلب البحث عن البيانات، وما داموا يستخدمون حساباتهم. من منظور أمني، يعني ذلك أنّه في حال اختراق الحساب، سيتمكّن أي فرد لديه إذن الوصول إلى الحساب من الوصول إلى بيانات BigQuery بدون أيّ قيود إضافية.

يمكن فرض مزيد من القيود من خلال استخدام قواعد مستوى الوصول في الدخول والخروج لتحديد سياق المستخدم. على سبيل المثال، يمكنك السماح بالوصول استنادًا إلى عنوان IP المصدر بالتزامن مع قاعدة دخول تم إعدادها سابقًا تسمح بالوصول عن طريق هوية المتصل. يمكن الوصول باستخدام عنوان IP المصدر لكلّ من نطاقَي CIDR العامَين لعنوان IP، بشرط أن يكون لعميل المستخدم عنوان IP علني تم تعيينه له أو من خلال استخدام عنوان IP داخلي إذا كان عميل المستخدم يعمل من خلال مشروع على Google Cloud.

إنشاء مستوى وصول باستخدام شرط الوصول إلى عنوان IP الداخلي

ضمن مجلد سياسة الوصول المُفصَّل نفسه، افتح صفحة Access Context Manager لإنشاء مستوى وصول.

1. في صفحة "مدير سياق الوصول"، اختَر إنشاء مستوى الوصول.
2. في جزء "مستوى الوصول الجديد":
   1. أدخِل عنوانًا: يمكنك استخدام codelab-al.
   2. في قسم "الشروط"، انقر على الشبكات الفرعية لعنوان IP.
   3. اختَر علامة التبويب عنوان IP خاص وانقر على اختيار شبكات VPC.
   4. من لوحة إضافة شبكات VPC، يمكنك تصفُّح شبكة default والعثور عليها أو إدخال اسم الشبكة بالكامل يدويًا بتنسيق //compute.googleapis.com/projects/project-2/global/networks/default.
   5. انقر على إضافة شبكة VPC.
   6. انقر على اختيار شبكات فرعية لعناوين IP.
   7. اختَر المنطقة التي يوجد فيها مثيل الجهاز الافتراضي (VM). هذا الدرس التطبيقي حول الترميز هو us-central1.
   8. انقر على حفظ.

لقد أنشأنا مستوى وصول لم يتم فرضه بعد على أي سياسة محيط أو سياسة للدخول أو الخروج.

إضافة مستوى الوصول إلى قاعدة الدخول

لفرض التحقق أيضًا من المستخدم الذي تسمح به قاعدة الدخول على مستوى الوصول، لابد من ضبط مستوى الوصول في قاعدة الدخول. قاعدة الدخول التي تسمح بالوصول إلى بيانات طلب البحث متوفّرة في perimeter-1. تغيير قاعدة الدخول لتحديد المصدر على أنّه مستوى الوصول codelab-al

اختبار الإعدادات الجديدة

بعد إضافة مستوى الوصول إلى قاعدة الدخول، سيتعذر تنفيذ طلب BigQuery نفسه ما لم يتم تنفيذه من العميل في شبكة VPC default للمشروع project-2. للتحقّق من هذا السلوك، يمكنك تنفيذ الطلب من وحدة التحكّم في Google Cloud أثناء اتصال جهاز نقطة النهاية بالإنترنت. سيتم إنهاء طلب البحث بشكل غير ناجح، وسيصاحب ذلك إشارة إلى انتهاك سياسة الدخول.

بشكل تلقائي:

• يتم ضبط نطاق الوصول إلى مثيل Compute Engine تلقائيًا على الوصول التلقائي، ما لا يسمح بالوصول إلى BigQuery API.
• سيتم ربط حساب الخدمة التلقائي في Compute Engine بمثيل Compute Engine. وفي الوقت نفسه، سيتم تشغيل جميع الأوامر التي يتم تشغيلها من الجهاز الافتراضي كحساب الخدمة هذا، والذي يجب أن يكون بالتنسيق [e-mail].
  يمكن تغيير كل من نطاق الوصول وحساب الخدمة المرتبط بالجهاز الافتراضي.

يمكن تنفيذ طلب البحث نفسه من شبكة VPC default الموجودة في project-2. وبالمثل، سيتعذّر أيضًا تنفيذ طلب BigQuery نفسه من مثيل Compute Engine المتوفّر في project-2 باستخدام شبكة VPC default. ويرجع ذلك إلى أنّ قاعدة الدخول ما زالت مضبوطة على السماح بسياسة [e-mail] الأساسية فقط. ومع ذلك، يستخدم الجهاز الافتراضي حساب الخدمة التلقائي في Compute Engine.

لتشغيل الأمر نفسه بنجاح من مثيل Compute Engine في project-2، يجب التأكّد مما يلي:

• يمتلك الجهاز الافتراضي نطاق وصول لاستخدام BigQuery API. ويمكن إجراء ذلك من خلال اختيار السماح بالوصول الكامل إلى جميع واجهات Cloud APIs كنطاق للوصول إلى الجهاز الافتراضي.
• يحتاج حساب الخدمة المرتبط بالجهاز الافتراضي إلى أذونات "إدارة الهوية وإمكانية الوصول" لتنفيذ ما يلي:
  • إنشاء مهام BigQuery في project-2
  • الحصول على بيانات BigQuery من جدول BigQuery في project-1
• يجب أن تسمح قاعدة الدخول والخروج بحساب خدمة Compute Engine التلقائي.

نحتاج الآن إلى إضافة حساب الخدمة التلقائي في Compute Engine إلى قواعد الدخول (للسماح بالحصول على البيانات من جدول BigQuery) وإلى قاعدة الخروج (للسماح بإنشاء مهام BigQuery).

من مثيل Compute Engine في project-2 على شبكة VPC في default، شغِّل أمر طلب البحث bq التالي:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

باستخدام الإعدادات الحالية، لن ينجح الأمر BigQuery إلا في الحالات التالية:

• تشغيله على جهاز افتراضي باستخدام شبكة VPC التلقائية في project-2
• تقع في منطقة us-central1 المحدّدة (الشبكة الفرعية لعنوان IP)
• التشغيل باستخدام حساب خدمة Compute Engine التلقائي الذي تم إعداده في محيط الخدمة.

سيفشل استعلام أمر BigQuery في حالة تشغيله من أي مكان آخر، بما في ذلك:

• إذا كان يتم تشغيلها على جهاز افتراضي باستخدام شبكة VPC التلقائية في project-2 ولكن تقع في منطقة مختلفة عن الشبكة الفرعية المضافة في مستوى الوصول
• إذا كان يتم تشغيلها من قِبل المستخدم [e-mail] من خلال برنامج مستخدم على الإنترنت

يوضّح هذا المخطّط البياني عملية الوصول التي بدأها مدير البيانات نفسه، [e-mail]، من موقعَين مختلفَين: الإنترنت ومثيل Compute Engine. تحظر عناصر التحكّم في خدمة سحابة VPC الوصول إلى BigQuery مباشرةً من الإنترنت (خطوط منقطة زرقاء)، بينما يُسمح بالوصول من جهاز افتراضي (خطوط متصلة خضراء) - أثناء انتحال هوية حساب الخدمة التلقائي في Compute Engine. يرجع الوصول المسموح به إلى ضبط محيط الخدمة للسماح بالوصول إلى الموارد المحمية من عنوان IP داخلي.

8. تنظيف

لا يتم فرض رسوم منفصلة مقابل استخدام عناصر التحكّم في خدمة "سحابة VPC" عندما لا تكون الخدمة قيد الاستخدام، إلّا أنّه من أفضل الممارسات تنظيف الإعدادات المستخدَمة في هذا المختبر. يمكنك أيضًا حذف مثيل الجهاز الافتراضي ومجموعات بيانات BigQuery أو مشاريع Google Cloud لتجنُّب تحمُّل الرسوم. يؤدي حذف المشروع على Google Cloud إلى إيقاف الفوترة لجميع الموارد المستخدَمة في هذا المشروع.

• لحذف مثيل الجهاز الافتراضي، أكمِل الخطوات التالية:
  • في وحدة تحكُّم Google Cloud، انتقِل إلى صفحة مثيلات الجهاز الافتراضي (VM).
  • ضَع علامة في مربّع الاختيار على الجانب الأيمن من اسم مثيل الجهاز الافتراضي، ثم اختَر حذف، ثم انقر على حذف مرة أخرى للتأكيد.
• لحذف محيط الخدمة، أكمِل الخطوات التالية:
  • في Google Cloud Console، اختَر الأمان، ثم عناصر التحكّم في خدمة VC على المستوى الذي يتم فيه نطاق سياسة الوصول، في هذه الحالة على مستوى المجلد.
  • في صفحة "عناصر التحكّم في خدمة سحابة VPC"، انقر على حذف في صف الجدول المقابل للمحيط الذي تريد حذفه.
• لحذف مستوى الوصول، أكمِل الخطوات التالية:
  • في Google Cloud Console، افتح صفحة Access Context Manager في نطاق المجلد.
  • في الشبكة، حدِّد صف مستوى الوصول الذي تريد حذفه، وانقر على قائمة الخيارات الإضافية، ثم على حذف.
• لإيقاف المشاريع، أكمِل الخطوات التالية:
  • في وحدة تحكم Google Cloud، انتقل إلى إدارة الهوية وإمكانية الوصول "إعدادات المشرف" للمشروع الذي تريد حذفه.
  • في إدارة الهوية وإمكانية الوصول اختَر إيقاف التشغيل في صفحة "إعدادات المشرف".
  • أدخِل رقم تعريف المشروع، واختَر إيقاف التشغيل على أي حال.

9. تهانينا!

في هذا الدرس التطبيقي حول الترميز، أنشأت محيطًا بعناصر التحكّم في خدمة "سحابة VPC" وفرضته وأصلحته وتحديد المشاكل فيه وحلّها.

مزيد من المعلومات

يمكنك أيضًا استكشاف السيناريوهات التالية:

• نفِّذ الطلب نفسه على مجموعة البيانات العامة، بعد أن تتم حماية المشروع باستخدام عناصر التحكّم في خدمة سحابة VPC.
• أضِف project-2 في المحيط نفسه مثل project-1.
• يُرجى إضافة "project-2" في محيطه الخاص والاحتفاظ بـ "project-1" في المحيط الحالي.
• يمكنك تنفيذ طلبات البحث لتعديل البيانات في الجدول، وليس فقط لاسترداد البيانات.

الترخيص

هذا العمل مرخّص بموجب رخصة المشاع الإبداعي 2.0 مع نسب العمل إلى مؤلف عام.