🇬🇧 English Version: Read the original article in English here.

إطلاق الصاروخ بالمفتاحين: حراس أمان SQLcl المحكمة للـ Deployments 🔑🚀

الجزء السابع (مسك الختام) من سلسلة “مطور APEX المدعوم بالذكاء الاصطناعي”.

⚡ الخلاصة في كلمتين (TL;DR)

إنك تدي لـ AI Coding Assistant أو لسكربت آلي اتصال داتابيز مفتوح بصلاحيات DBA خارقة، ده بالظبط زي ما تدي طفل صغير في إيده منشار خشب كهربائي شغال وتقوله “قصقص لنا شوية ورد من الجنينة”! مجرد سوء فهم بسيط، وهتلاقي شجرة الـ Production اتقصت من قاعها ومبقاش ليها أثر!

في ختام السلسلة دي، هنشوف إزاي نبني شبكة أمان لا تخترق عن طريق دمج 3 اتصالات SQLcl معزولة الصلاحيات مع فحوصات تأكيد هوية البيئة والـ Schema قبل تشغيل أي سطر كود.

المعمارية دي مستوحاة من غرف تحكم الغواصات الحربية، حيث إطلاق الصاروخ بيتطلب مفتاحين منفصلين بيلفهم ضابطين في نفس اللحظة—عشان نضمن إن لا AI شارد ولا مطور مرهق الساعة 3 الفجر يقدر ينفذ سكربت بالغلط على الداتابيز الحية!

💥 ورطة المنشار الكهربائي: الصلاحيات في عصر الذكاء الاصطناعي

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

الصبح بيشوف إحصائيات الجداول.
الظهر بيجرب استعلام SELECT سريع.
العصر بيشغل سكربت ALTER TABLE تجريبي.
وبالليل بيصلح Bug طارئة في السيرفر!

لو إنسان غلط بالاتصال ده، ممكن في أسوأ الظروف يمسح جدول بالغلط.

لكن تخيل بقى لما تحط في المعادلة AI Agent ذاتي التوجيه بيكتب وينفذ أكواد بسرعة 100 سطر في الثانية! لو الـ Agent ده شغال بيوزر DBA مفتوح وهبد أمر DROP TABLE ORDERS CASCADE CONSTRAINTS PURGE، خطة طوارئ الكوارث (Disaster Recovery) هتشتغل قبل ما تلحق تمد إيدك وتدوس Ctrl+C!

وكلاء الذكاء الاصطناعي أدوات تسريع مذهلة، بس بيشتغلوا بنظام احتمالي (Probabilistic). وحسب مبدأ أقل صلاحيات ممكنة (Principle of Least Privilege)، مستحيل الـ Agent ياخد صلاحية أكبر من الحد الأدنى الصارم للمهمة اللي رايح يعملها حالا.

🔑 مبدأ كروت الأمان الثلاثة (The 3 Keycards)

عشان نخلي عمليات الداتابيز آمنة بنسبة 100%، استبدلنا المفتاح السحري الواحد بـ 3 اتصالات مسماة ومعزولة الصلاحيات جوه SQLcl:

1. READER_SQLCL_CONNECTION   → 🔍 كارت القراءة فقط (للبحث والاستعلامات)
2. DEPLOYER_SQLCL_CONNECTION → 🛠️ كارت المطور المحدود (DDL/DML جوه DEV بس)
3. METADATA_SQLCL_CONNECTION → 🪞 كارت المراية (لتشغيل DBMS_METADATA فقط)

تعالوا نشوف حدود كل كارت فيهم:

الكارت 1: القارئ (`READER_SQLCL_CONNECTION`)

الصلاحية: واخد صلاحية SELECT فقط على جداول التطبيق وقواميس الداتابيز (ALL_TABLES, ALL_DEPENDENCIES).
عمليات الـ DDL والـ DML: ممنوعة منعاً باتاً. مستحيل يعمل INSERT أو UPDATE أو DROP.
بيشتغل إمتى: لما الـ AI بيحقق في bug، أو بيفحص العلاقات، أو بيتأكد من أنواع الأعمدة. حتى لو الـ AI اتجنن وطلع أمر مسح، محرك أوراكل هيرميه في وشه بإيرور ORA-01031: insufficient privileges.

الكارت 2: الناشر (`DEPLOYER_SQLCL_CONNECTION`)

الصلاحية: واخد صلاحيات كتابة مقفولة بالمللي جوه سكيما التطوير فقط (زي APP_CODE).
بيشتغل إمتى: لما توافق على السكربتات المجهزة في ai_generate/YYYY-MM-DD/ وتشغلها على جهازك أو سيرفر الـ Dev. معندوش أي وصول لسيرفرات الـ Production أو الـ Staging.

الكارت 3: مراية الميتاداتا (`METADATA_SQLCL_CONNECTION`)

الصلاحية: يوزر مخصص ومقيد لتشغيل حزم DBMS_METADATA وسحب ملفات التصدير عبر SQLcl.
بيشتغل إمتى: بيشتغل أوتوماتيكياً في خلفية سكربتات المزامنة لتحديث فاترينة database/<schema>/.

بحفظ الاتصالات دي في مخزن SQLcl المشفر (conn -save <name>)، السكربتات بتتنقل بين الاتصالات بالأسماء المستعارة من غير ما تعرض باسووردات على المكشوف في الشات:

sql /nolog
conn -save DEV_READER my_reader_user/secret_pass@dev_db
conn -save DEV_DEPLOYER my_code_user/secret_pass@dev_db

🚀 كونسول الغواصة المزدوج: فحوصات تأكيد السكيما قبل التنفيذ

إنك تعمل اتصالات بأسماء مستعارة ده شيء عظيم، بس إيه اللي يضمن إن سكربت مخصص لداتابيز APP_DEV ميروحش يتنفذ بالغلط على APP_PROD؟

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

في الـ Pipeline بتاعنا، بنطبق نفس الأمان الصارم ده بإضافة بلوك فحص واختبار أمان إجباري (Pre-Flight Assertion Guard) في أول كل سكربت Migration بيتولد في ai_generate/:

-- ====================================================================
-- سكربت: ai_generate/2026-09-05/01_deploy_customer_loyalty.sql
-- بلوك اختبار وتأكيد الأمان قبل تنفيذ أي سطر
-- ====================================================================

-- 1. لو حصل أي خطأ.. اخرج فوراً واعمل Rollback لكل حاجة!
whenever sqlerror exit failure rollback;
set serveroutput on;

declare
    c_expected_schema constant varchar2(30) := 'APP_CODE';
    c_forbidden_db    constant varchar2(30) := 'PROD_DB';
    
    v_current_schema  varchar2(30);
    v_current_db      varchar2(30);
begin
    -- استخراج بيانات السيشن النشطة حالياً
    select sys_context('USERENV', 'CURRENT_SCHEMA'),
           sys_context('USERENV', 'DB_NAME')
      into v_current_schema,
           v_current_db
      from dual;

    -- الفحص 1: رفض قاطع لو الداتابيز هي الـ Production المحمية
    if upper(v_current_db) = c_forbidden_db then
        raise_application_error(-20001,
            '🚨 إنذار أحمر! محاولة تنفيذ سكربت على داتابيز الـ Production المحمية: ' || 
            v_current_db || '. تم إيقاف العملية فوراً!');
    end if;

    -- الفحص 2: التأكد من مطابقة السكيما المتصلة بالسكيما المستهدفة
    if upper(v_current_schema) != c_expected_schema then
        raise_application_error(-20002,
            '⚠️ تضارب في السكيما! السكربت مصمم لـ [' || c_expected_schema || 
            '] وأنت متصل حالياً بـ [' || v_current_schema || ']. تم إلغاء العملية.');
    end if;

    dbms_output.put_line('====================================================');
    dbms_output.put_line('✓ فحص الأمان نجح: متصل بـ ' || v_current_schema || ' على داتابيز ' || v_current_db);
    dbms_output.put_line('====================================================');
end;
/

-- ====================================================================
-- كود الـ DDL أو الـ DML الحقيقي بيبدأ هنا بعد نجاح الفحص
-- ====================================================================
ALTER TABLE CUSTOMERS ADD (
    LOYALTY_POINTS NUMBER(10,0) DEFAULT 0 NOT NULL,
    LOYALTY_TIER   VARCHAR2(20) DEFAULT 'BRONZE' NOT NULL
);

إيه اللي بيحصل لما يقع خطأ؟

لو حد بالغلط شغل السكربت ده وهو متصل بداتابيز تانية:

كشف فوري في أجزاء من الثانية: الأسطر الأولى بتفحص CURRENT_SCHEMA و DB_NAME. لو مفيش تطابق، كود الـ PL/SQL بيرمي خطأ غير معالج (ORA-20001 أو ORA-20002).
تراجع فوري وخروج آمن (Instant Rollback & Exit): لأن أول سطر في الملف مكتوب فيه whenever sqlerror exit failure rollback، أداة SQLcl بتلقط الخطأ فوراً، وتلغي أي تعديل معلق، وتقفل الجلسة وتخرج بكود فشل.
ولا سطر كود بيتنفذ: أمر الـ ALTER TABLE اللي مكتوب تحت مستحيل يتقرأ أو يدخل محرك الداتابيز أصلاً!

داتابيز الإنتاج بتاعتك محمية ومستحيل تنضرب بالخطأ! 🛡️

🏁 الأعمدة السبعة لمطور Oracle APEX المدعوم بالذكاء الاصطناعي

على مدار السلسلة دي المكونة من 7 أجزاء، بنينا نموذج عمل هندسي متكامل للمؤسسات:

معمارية مطور APEX الحديث:
┌──────────────────────────────────────────────────────────┐
│ 7. حراس الـ Deployments بالمفتاحين وفحوصات SQLcl         │  ← أمان حديدي
├──────────────────────────────────────────────────────────┤
│ 6. جلسة التعارف والذاكرة الدائمة بفولدر app_context/    │  ← صفر زهايمر
├──────────────────────────────────────────────────────────┤
│ 5. تقسيم المعمل النظيف لـ 4 مناطق (Apps / Mirror / Stage)│  ← مفيش خلط
├──────────────────────────────────────────────────────────┤
│ 4. استعلامات الجراف بدون هدر عبر Graphify CLI            │  ← توفير 90% توكنز
├──────────────────────────────────────────────────────────┤
│ 3. الـ AST Architectural Knowledge Graph                 │  ← الحقيقة المعمارية
├──────────────────────────────────────────────────────────┤
│ 2. التقسيم الذكي بلغة APEXlang (.apx)                    │  ← Git Diffs نظيفة
├──────────────────────────────────────────────────────────┤
│ 1. الهروب من فخ ملفات الـ SQL الضخمة والتوكنز            │  ← سرعة وتوفير
└──────────────────────────────────────────────────────────┘

هربنا من فخ التوكنز: بطلنا نرمي 150 ألف سطر للـ AI ووفرنا فواتير الـ API من الجذور.
اتعلمنا APEXlang (.apx): فككنا التطبيقات لملفات مقروءة وواضحة للبشر والذكاء الاصطناعي.
بنينا الـ Knowledge Graph: رسمنا شاشاتنا وزرايرنا وجداولنا في شبكة علاقات هندسية قطعية.
استعلمنا بدون هدر: استخدمنا Graphify عشان نسحب الـ 10 نود المطلوبين بالمللي لكل ميزة.
فرضنا معمارية المعمل النظيف: 4 فولدرات فيزيائية بتمنع خلط الكود الحي بمرايات الداتابيز وتجارب الـ AI.
قضينا على زهايمر الـ LLMs: فولدر app_context/ وأمر /init بيخلوا الـ AI جاهز في 30 ثانية.
حمينا الـ Deployments: بنينا حراس الأمان المزدوجة في SQLcl لمنع أي أخطاء في الـ Production.

🛠️ ابنيها بنفسك، أو انطلق بالقالب الجاهز

كل تقنية ومعمارية اتشرحت في السلسلة دي هي مبادئ هندسية مفتوحة (Open Engineering Principles). تقدر تطبقها فوراً في مشروعاتك القائمة، سواء شغال بـ Git أو Jenkins أو GitLab CI أو Cursor أو غيرهم.

لكن لو عايز تنطلق بنموذج مجرب وناجح الأعمدة السبعة فيه متظبطة وشغالة وجاهزة للانطلاق فوراً:

👉 شوف APEX Project Template المفتوح المصدر على GitHub!

جواه هتلاقي:

تقسيم المعمل النظيف لـ 4 فولدرات جاهز.
سكربتات استخراج الـ AST والـ Graphify جاهزة (setup_graphify_apx.py).
قوالب app_context/<app-id>/ وأمر التهيئة السريع /init.
حراس الأمان لـ SQLcl والاتصالات المعزولة مسبقاً.

سواء عملت Clone للقالب أو اقتبست منه أفكار لمشروعك، دلوقتي بقى معاك الأدوات الحقيقية عشان تبني تطبيقات Oracle APEX أسرع، وأنظف، وأكثر استقراراً من أي وقت مضى.

برمجة ممتعة للجميع، ومرحباً بكم في مستقبل تطوير Oracle APEX مع الذكاء الاصطناعي! 🚀✨

كتبه: أحمد شريف (Ahmed Sherif).