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

1. مقدمة

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

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

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

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

قبل البدء

في هذا الدرس العملي، نفترض أنّك تعرف ما يلي:

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

الإعداد

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

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

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

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

إنشاء حيّز خدمة عادي

في هذا الدرس التطبيقي العملي، سنستخدم محيط خدمة عاديًا يحمي 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. (اختَر إنشاء مجموعة بيانات جديدة، ما لم تكن تستخدم مجموعة بيانات حالية).
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;

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

سيكون سجلّ تدقيق الانتهاكات في 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 Console (أو أداة سطر الأوامر 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] بتجاوز حدود المحيط.
• TO | المشاريع: لا يمكن للهوية المحدّدة تجاوز حدود المحيط إلا إذا كانت الوجهة هي المشروع المحدّد project-2.
• TO | الخدمات: يمكن للهوية المحدّدة بدء نقل البيانات خارج المحيط، باتجاه المشروع المحدّد فقط إذا كان طلب البيانات من واجهة برمجة التطبيقات مخصّصًا للخدمة والطريقة المحدّدتين. بخلاف ذلك، إذا حاولوا مثلاً استخدام خدمة مختلفة محمية بحدود الخدمة، سيتم حظر العملية لأنّه لا يُسمح باستخدام خدمات أخرى.

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

بعد وضع قاعدة الخروج، نفِّذ طلب البحث نفسه.

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.

من المهم فهم طريقة عمل خدمة واجهة برمجة التطبيقات المحدّدة من أجل توقّع الانتهاكات المحتملة.

6. إصلاح المخالفة للحصول على بيانات جدول BigQuery

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

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

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

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

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

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

من الآن فصاعدًا، يجب أن يتم تنفيذ طلب البحث المطابق بشكلٍ سليم بدون حدوث أي مخالفات لعناصر التحكّم في خدمة سحابة VPC.

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

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

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

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

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

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

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

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

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

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

من أجل فرض التحقّق من المستخدم المسموح به بموجب قاعدة الدخول أيضًا مقابل مستوى الوصول، من الضروري ضبط مستوى الوصول في قاعدة الدخول. قاعدة الدخول التي تسمح بالوصول إلى بيانات طلب البحث موجودة في 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. يمكن إجراء ذلك من خلال اختيار السماح بالوصول الكامل إلى جميع واجهات برمجة التطبيقات على السحابة الإلكترونية كنطاق الوصول إلى الجهاز الظاهري.
• يجب أن يمتلك حساب الخدمة المرتبط بالجهاز الظاهري أذونات إدارة الهوية وإمكانية الوصول (IAM) لإجراء ما يلي:
  • إنشاء وظائف 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 لتجنُّب تحمّل رسوم. يؤدي حذف مشروع Cloud إلى إيقاف الفوترة لجميع الموارد المستخدَمة في هذا المشروع.

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

9- تهانينا!

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

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

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

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

الترخيص

يخضع هذا العمل لترخيص Creative Commons Attribution 2.0 Generic License.