كان كل تطبيق لدينا جزيرة معزولة: كيف أنقذتنا ‘شبكات VPC’ من جحيم التعقيد الأمني؟

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

في يوم من الأيام، وأنا بشرب فنجان القهوة الصباحي وبراجع سجلات الخوادم، لمحت إشي غريب. حركة مرور (traffic) غير طبيعية على قاعدة البيانات الخاصة بتطبيق المستخدمين. قلبي بلش يدق بسرعة. يا زلمة، قاعدة البيانات هاي المفروض ما حدا يوصلها إلا الخدمة الخلفية تبعتها، كيف صار في طلبات مباشرة من الإنترنت؟ بعد شوية تحقيق، اكتشفنا إنه واحد من المطورين الجداد، بحسن نية، فتح بورت (منفذ) على قاعدة البيانات عشان يشتغل من البيت بسهولة ونسي يسكره! الحمد لله إنه اكتشفنا الموضوع بسرعة قبل ما يصير اختراق حقيقي، لكن الحادثة هاي كانت زي صفعة صحتنا كلنا.

وقتها أدركنا الحقيقة المرة: بنيتنا التحتية كانت عبارة عن مجموعة جزر معزولة. كل تطبيق عايش لحاله، قواعد الأمان فيه مرقعة ترقيع، والاتصال بين الخدمات بصير إما عبر الإنترنت العام أو عبر طرق ملتوية ومعقدة. كان الوضع فوضوي، وغير آمن، وغير قابل للتوسع. كان لازم نلاقي حل جذري. وهنا دخلت شبكات VPC (Virtual Private Cloud) على الخط، وأنقذتنا من جحيم كنا عايشين فيه بدون ما نعرف.

ما هي شبكة VPC أصلاً؟ وليش لازم تهتم؟

ببساطة شديدة، تخيل إنه مزود الخدمة السحابية (زي AWS, Azure, Google Cloud) هو مدينة ضخمة جداً ومفتوحة للكل. شبكة VPC هي قطعة أرض خاصة فيك داخل هاي المدينة. أنت بتبني حواليها سور، وبتحط عليها بوابات وحراس، وبتقسمها من جوا زي ما بدك: هنا منطقة سكنية (لقواعد البيانات)، وهنا منطقة تجارية (لخوادم الويب)، وهنا منطقة صناعية (لخدمات معالجة البيانات). أنت المتحكم الوحيد مين يدخل ومين يطلع، وكيف الأجزاء المختلفة تتكلم مع بعضها.

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

لماذا الجزر المنعزلة كانت كابوساً؟

قبل الـ VPC المنظمة، كانت حياتنا عبارة عن المشاكل التالية:

• الكابوس الأمني: كل خادم كان معرض للإنترنت بشكل أو بآخر. إدارة قواعد الجدار الناري (Firewall rules) كانت تتم على مستوى كل خادم لحاله. تخيل عندك 100 خادم، يعني 100 مكان ممكن تغلط فيه وتفتح ثغرة أمنية.
• فوضى الاتصال: لما خدمة “الفواتير” بدها تحكي مع خدمة “المستخدمين”، كان لازم نستخدم عناوين IP عامة. هذا يعني أن الاتصال بيطلع على الإنترنت وبيرجع يدخل! بطيء، غير آمن، ومكلف.
• صداع إدارة العناوين (IP Management): ما كان عنا أي خطة لعناوين IP. كنا نستخدم العناوين اللي بتعطينا إياها السحابة بشكل عشوائي، وهذا أدى لتضارب في العناوين وصعوبة في تتبع مين بحكي مع مين.

بناء القلعة الرقمية: مكونات شبكة VPC

لما قررنا نبني أول VPC صح، حسينا حالنا بنبني قلعة. وكل جزء فيها له وظيفة مهمة. خلونا نتعرف على هاي الأجزاء قطعة قطعة.

1. CIDR Block: حجر الأساس

أول قرار بتاخده هو حجم قطعة الأرض تبعتك. الـ CIDR (Classless Inter-Domain Routing) هو ببساطة نطاق عناوين IP اللي راح تستخدمها في شبكتك. مثلاً، 10.0.0.0/16 بيعطيك حوالي 65,536 عنوان IP. هذا هو حجر الأساس لكل شبكتك.

نصيحة من أبو عمر: خليك كريم! اختار نطاق CIDR كبير من البداية. ما بتقدر تغيره بعدين بسهولة. حتى لو بتفكر إنك محتاج 100 عنوان بس، اختار نطاق فيه آلاف. التوسع المستقبلي راح يكون أسهل بكثير، وراح تتجنب مشاكل تضارب العناوين مع شبكات أخرى ممكن تحتاج تتصل فيها (زي شبكة مكتبك أو VPCs أخرى).

2. Subnets (الشبكات الفرعية): تقسيم المملكة

بعد ما أخذت قطعة الأرض الكبيرة (VPC)، لازم تقسمها لقطع أصغر. هاي هي الـ Subnets. التقسيم الأكثر شيوعاً هو:

• Public Subnets (شبكات فرعية عامة): هاي القطع اللي إلها واجهة مباشرة على الإنترنت. بنحط فيها الأشياء اللي لازم الناس توصلها من برا، زي موازنات التحميل (Load Balancers) أو خوادم الويب الأمامية.
• Private Subnets (شبكات فرعية خاصة): هاي هي المناطق المحمية داخل قلعتك. ما إلها أي اتصال مباشر من الإنترنت. بنحط فيها كنوزنا: قواعد البيانات، الخدمات الخلفية الحساسة، وأي إشي ما بدنا حدا يوصله من برا.

3. Route Tables (جداول التوجيه): شرطي المرور

كل شبكة فرعية (Subnet) عندها جدول توجيه. هذا الجدول هو اللي بقرر وين تروح حزم البيانات (packets). هو بمثابة شرطي المرور اللي بيوجه السيارات. مثلاً:

• في الـ Public Subnet، جدول التوجيه بقول: “أي إشي رايح على الإنترنت، وديه على البوابة الفلانية (Internet Gateway)”.
• في الـ Private Subnet، جدول التوجيه بقول: “أي إشي رايح على الإنترنت (للتحديثات مثلاً)، وديه على المترجم الفلاني (NAT Gateway)”.

4. Internet Gateway (IGW) و NAT Gateway

• Internet Gateway (IGW): هاي هي البوابة الرئيسية لقلعتك على العالم الخارجي (الإنترنت). بدونها، الـ VPC تبعتك بتكون معزولة تماماً. هي اللي بتسمح للـ Public Subnets بالتواصل مع الإنترنت.
• NAT Gateway: هذا مكون ذكي جداً. هو عبارة عن “مترجم” بيقعد في الـ Public Subnet. وظيفته يسمح للخوادم اللي في الـ Private Subnets إنها تطلع على الإنترنت (عشان تعمل تحديثات مثلاً أو تتصل بـ APIs خارجية)، لكن ما بسمح لأي حدا من الإنترنت إنه يبدأ اتصال مع هاي الخوادم الخاصة. بحميها وبيخفيها.

5. Security Groups و Network ACLs: الحراس

هنا يكمن لب الأمان. عندك نوعين من الحراس:

• Security Groups (مجموعات الأمان): هدول الحراس الشخصيين اللي بيوقفوا على باب كل خادم (EC2 instance). هم “Stateful”، يعني لو سمحت بطلب يطلع، هو تلقائياً بسمح للرد إنه يرجع. القاعدة العامة هنا: “امنع كل شيء، واسمح فقط بما تحتاجه”. مثلاً، السيرفر تبع الويب، اسمح له يستقبل طلبات على بورت 80 و 443 فقط من أي مكان في العالم. قاعدة البيانات، اسمح لها تستقبل طلبات على بورت 3306 فقط من الـ Security Group تبعت خوادم التطبيق.
• Network ACLs (قوائم التحكم في الوصول للشبكة): هدول حرس الحدود اللي بيوقفوا على حدود كل شبكة فرعية (Subnet). هم “Stateless”، يعني لازم تسمح بطلب الذهاب وطلب الإياب بشكل صريح. هم خط دفاعك الأول، لكنهم أقل مرونة من الـ Security Groups.

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

مثال عملي: من الفوضى إلى النظام

خلونا نصمم بنية تحتية بسيطة وآمنة لتطبيق ويب من ثلاث طبقات (Web, App, DB) باستخدام المكونات اللي حكينا عنها.

1. VPC: نختار CIDR 10.20.0.0/16.
2. Subnets:
   • 2 Public Subnets (مثلاً 10.20.1.0/24 و 10.20.2.0/24) في منطقتي توافر (Availability Zones) مختلفتين لضمان الاستمرارية.
   • 2 Private Subnets (مثلاً 10.20.101.0/24 و 10.20.102.0/24) في نفس منطقتي التوافر.
3. Gateways:
   • Internet Gateway واحد للـ VPC كلها.
   • NAT Gateway واحد نضعه في أحد الـ Public Subnets.
4. Route Tables:
   • جدول توجيه للـ Public Subnets يوجه كل الترافيك (0.0.0.0/0) إلى الـ IGW.
   • جدول توجيه للـ Private Subnets يوجه كل الترافيك (0.0.0.0/0) إلى الـ NAT Gateway.
5. Security Groups:
   • sg-loadbalancer: يسمح بالاتصال على بورت 80/443 من الجميع (0.0.0.0/0).
   • sg-web-servers: يسمح بالاتصال على بورت 80/443 فقط من sg-loadbalancer.
   • sg-app-servers: يسمح بالاتصال على بورت التطبيق (مثلاً 8080) فقط من sg-web-servers.
   • sg-database: يسمح بالاتصال على بورت قاعدة البيانات (مثلاً 3306) فقط من sg-app-servers.

بهذا التصميم، لا يمكن لأي شخص الوصول إلى قاعدة البيانات مباشرة من الإنترنت. حتى خوادم الويب لا يمكن الوصول إليها إلا من خلال موازن التحميل. هذا هو معنى الدفاع في العمق (Defense in Depth).

شوية كود يا جماعة (مثال بـ Terraform)

الكلام النظري حلو، بس الأتمتة أحلى. كتابة البنية التحتية ككود (Infrastructure as Code) بتضمن التكرار وتجنب الأخطاء البشرية. هذا مثال بسيط جداً باستخدام Terraform لتعريف VPC وشبكة فرعية عامة.

# provider.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

# vpc.tf
resource "aws_vpc" "main_vpc" {
  cidr_block           = "10.20.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "My-Awesome-VPC"
  }
}

resource "aws_subnet" "public_subnet_1" {
  vpc_id                  = aws_vpc.main_vpc.id
  cidr_block              = "10.20.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true # Important for public subnets

  tags = {
    Name = "Public-Subnet-1"
  }
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main_vpc.id

  tags = {
    Name = "Main-IGW"
  }
}

resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }

  tags = {
    Name = "Public-Route-Table"
  }
}

resource "aws_route_table_association" "a" {
  subnet_id      = aws_subnet.public_subnet_1.id
  route_table_id = aws_route_table.public_rt.id
}

هذا الكود، عند تنفيذه، سيقوم ببناء أساس شبكتك في دقائق، وبشكل يمكنك إعادة استخدامه ومراجعته وتطويره.

الخلاصة: من جزر إلى قارة متصلة 🏝️➡️🌍

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

لا تخف من هذه المفاهيم. ابدأ ببساطة، صمم شبكة VPC واحدة لتطبيق واحد. تعلم المكونات، جرب، واكسر الأشياء (في بيئة تجريبية طبعاً!). مع الوقت، ستصبح هذه المفاهيم جزءاً من طبيعتك كمطور أو كمهندس سحابي. تذكر دائماً الدرس الذي تعلمناه بالطريقة الصعبة: في عالم السحابة، بناء الأسوار والجسور الصحيحة ليس خياراً، بل هو ضرورة.

أتمنى لكم بناء موفق وآمن، والله يعطيكم العافية.