VOL23: How Figma Secures Internal Web Applications
VOL23: How Figma Secures Internal Web Applications
أهلًا وسهلا بكم في العدد الثالث والعشرين من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثالث والعشرين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How Figma Secures Internal Web Application
Improving SQL Queries Tips and Tricks
Git Aliases
Java Exceptions Cheatsheet
API Authentication Methods
How Figma Secures Internal Web Application
فريق الأمان في Figma بنى نظام جديد عشان يوفروا وصول آمن للتطبيقات الداخلية بتاعتهم. فخلوني اشارك معاكم إيه اللي اتعلموه من التجربة دي، وإزاي النظام اصبح جزء ومنهج شامل للأمان عندهم.
النظام ده بيتيح الوصول للتطبيقات الداخلية بشكل آمن وباستخدام Reusable Cloud Components وبعض التقنيات الحديثة والآمنة. وكانوا شايفين إن النمط ده ممكن يفيد فرق تانية في خصوصا كمان في حماية التطبيقات الداخلية الحساسة بتاعتهم.
Context
زي أغلب شركات التكنولوجيا، Figma بتعتمد على مجموعة من التطبيقات الداخلية اللي هم طوروها بنفسهم ورا الكواليس. وده بداية من الـ Software Deployments لغاية دعم العمليات المختلفة في الـ Business، وأدوات الويب اللي طوروها مهمة جدًا في الـ Workflow بتاع الموظفين عندهم.
التطبيقات دي كمان لها متطلبات أمان شديدة جدًا عشان يضمنوا إن بس الموظفين المصرح لهم يقدروا يوصلوا ليها بشكل آمن.
وطبعًا زي ماحنا عارفين ان الـ Attackers والـ Cybercriminals عندهم باع وصيت في استهداف الأنظمة الإدارية كطريقة للوصول لبيانات المستخدمين وده شوفناه على مر السنين في تجارب لشركات كتيرة واللي أصبح دلوقتي موضوع غاية في الأهمية إن كل شركة تكون عندها نظام حماية قوي لخدماتها.
وعشان يحموا المستخدمين بتوعهم وبياناتهم من ان يحصل عليها أي اختراقات، اشتغلوا على بناء نظام يقدر يوفر وصول آمن للتطبيقات الداخلية بتاعتهم وتضمن وصول آمن للتطبيقات دي.
Approach
النهج بتاعهم بيعتمد على مكونات جاهزة بدلًا من اعادة صنع العجلة وده عشان يسهلوا عملية الصيانة اللي ممكن تكون كبيرة جدًا ويستفيدوا كذلك من تأثيرات الشبكات الأمنية اللي موجودة واللي اتبذل فيها مجهود كبير، لكن في نفس الوقت بدأوا يربطوها بطرق جديدة عشان يضمنوا تحقيق الـ Security Best Practices ومن البداية، كان عندهم مجموعة من المتطلبات:
تجربة مستخدم سلسة: إنتاجية الموظفين عندهم أولوية قصوى، فعشان كده نظام الـ Authentication بتاعهم لازم يكون سريع، موثوق، وسهل الوصول ليه.
مبدأ الـ Zero-Trust: إن الموظف يسجل الدخول من شبكة "موثوقة" مش كفاية لضمان الثقة. فلما بيحصل عملية Authentication للعملاء، نموذج الأمان بتاعهم لازم يكون معتمد على تأكيدات أقوى بكتير من مجرد الاعتماد على عنوان الشبكة لوحده.
إمكانيات Authentication حديثة وقوية: هم عاوزين يستفيدوا من أحدث وأفضل تقنيات أمان الويب الموجودة لحماية التطبيقات الداخلية بتاعتهم. لإنهم عارفين أهمية موضوع زي ده ، وأي مهندس بيشتغل على تطبيق داخلي لازم يقدر بسهولة يستفيد من الدفاعات دي زي WebAuthn داخل النظام اللي بيبنوه.
الـ Centralized Authorization: فرق الـ IT والأمان عندهم لازم يقدروا يوزعوا، ويراقبوا، ويعدلوا الصلاحيات اللي بيدوها للموظفين بشكل فعال. وده لإن النظام اللي بيكون موزع بزيادة هيبقى من الصعب فهمه أو التحكم فيه بسهولة، وهيؤدي بالشكل ده إما لمنح صلاحيات زيادة كتيرة لكل موظف أو لإحباط المستخدم.
أقل جهد لفريق الأمان: باعتبار ان فريق الآمان عندهم كان صغير ومعاهم جزء كبير محتاجين يأمنوه ومهمة صعبة، الحل بتاعهم كان الوصول للتطبيقات مش لازم يتطلب شغل SRE أو عمليات Operational كتير مستمرة.
الأدوات اللي استخدموها
SAML
AWS Application Load Balancer
AWS Cognito
AWS Lambda
Terraform
AWS Application Load Balancers & Okta مصدر الصورة: Figma Engineering Blog
Improving SQL Queries Tips and Tricks
بنسبة كبيرة في أغلب شغلنا كـ Backend Developers بنحتك بشكل كبير بقواعد البيانات ، وأصبح من المهم دلوقتي أن يكون عندنا مهارة قوية في التعامل مع الـ SQL ونكون فاهمين كويس ازاي نكتب Queries تكون قوية و Efficient عشان مندفعش ضريبتها في الـ Performance بتاع التطبيق اللي بنبنيه.
فتعالوا نشوف مع بعض بعض النصايح والـ Tips and Tricks اللي ممكن نستعملهم عشان نحسن من الـ SQL Query Performance.
SELECT *
من الشائع واللي أغلبنا اتعلمناه واحنا بندرس قواعد بيانات واللي بقينا بنستعمله بشكل كبير عشان بيسهل الدنيا علينا هي اننا نروح نعمل الـ SQL Query دي :
SELECT * FROM students;
المشكلة هنا ، ان بنسبة كبيرة جدًا أغلب اللي بنكون محتاجينه وقتها مش كل الـ Columns اللي موجودين في الـ Students Table ولكن بنكون محتاجين Columns محددة زي الاسم والعمر ، او ايا يكن .. ولكن مش كل البيانات!
فالـ SELECT * للأسف بتؤدي لمشاكل في الـ Performance خصوصا مع حجم البيانات المتزايد واللي هيكون موجود ولان ده من ورا بيتطلب ان يتعمل عشان يتنفذ Full Table Scan كـ Query Execution Plan.
طب الأفضل اعمل ايه ؟
الأفضل انك تختار وتحدد الـ Columns اللي انت محتاجها فقط لا غير زي كده :
SELECT student_id, name, email FROM students;
SELECT DISTNICT
كلنا اتعلمنا في بداية حياتنا ان عشان نرجع الـ Data وتكون Unique يعني مش مكررة ، بنستعمل DISTINCT ولكن للأسف اللي ما نعرفوش اننا بالشكل ده بنسبب مشكلة كبيرة في الـ Performance طب ليه ؟
لما بنيجي نستعمل جملة SQL Query زي الشكل ده :
SELECT DISTINCT city FROM students;
العملية دي بتكون مكلفة جدًا وده لإن من ورا واللي انت مش عارفه ان بيتم مقارنة كل Row مع الـ Rows التانية ، ومش بس كده ده الموضوع بيتطلب عمل Sorting / Filtering واللي بالطبع هيكون مكلف خصوصا في الـ Tables اللي فيها كميات كبيرة من البيانات.
فالأفضل دايمًا لو محتاجين اننا نـ Query Unique Data , اننا نعتمد على الـ Design زي ان يكون عندنا Primary Keys أو بعض الـ Unique Constraints اللي محطوطة.
وكحل بديل ممكن نستعمل الـ GROUP BY بالشكل الآتي :
SELECT city FROM students GROUP BY city;
فالـ GROUB BY هتكون مفيدة جدًا خصوصًا مع استعمال Indexing بشكل كويس.
الشراكات - Sponsorship
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع ، عشان يجيلكم كل جديد بينزل على اقرأ-تِك 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Git Aliases
من المعروف أن Git واحدة من أهم الأدوات اللي لازم كل مطور يكون على دراية بيها.
بنستخدم Git للتعامل مع النسخ المختلفة من المشروع، لكن بعض أوامر Git ممكن تكون طويلة ومعقدة شوية. هنا بيجي دور Git Aliases، اللي هي أسماء مستعارة بتكون من إنشائك علشان تخلي استخدام Git أسرع وأكثر كفاءة.
الهدف من الأسماء المستعارة (Aliases) هو إنها تكون اختصارات لأوامر Git الطويلة والمعقدة. بدلاً من كتابة الأوامر الكاملة في كل مرة، تقدر تنشئ اسم مستعار قصير وسهل تتذكره لتنفيذ نفس الأمر بسرعة.
فورقة وقلم وتعالوا نتكلم عن ازاي نقدر نستخدم Git Aliases في تسريع شغلنا 🚀
ازاي تنشئ اسم مستعار في Git؟
علشان تعمل كده، هتستخدم أمر git config بالشكل ده:
git config --global alias.<name> "<command>"استبدل <name> بالاسم المستعار اللي عايزه.
استبدل <command> بأمر Git الكامل اللي عايز تختصره.
أمثلة على الأسماء المستعارة في Git
اختصار git status:
git config --global alias.st "status"دلوقتي بدلاً من كتابة git status، ممكن تكتب git st.
اختصار git log --oneline --graph --decorate --all:
git config --global alias.lg "log --oneline --graph --decorate --all"Java Exceptions Cheatsheeet
الـ Exception Handling من الأساسيات في تعلم أي لغة ، وده لانك وانت شغال أكيد هيقابلك سيناريوهات هتضطر تـ Throw فيها Exceptions ، واحيانًا هتلاقيهم في وشك وأنت مش عارف ليه ، فلازم تكون فاهمهم كويس وعارف تتعامل معاهم ازاي.
فورقة وقلم وتعالوا نتعرف على الـ Java Exceptions و إزاي بنعملها Handeling بطريقة سليمة.
الكود عبارة عن "سيناريو" بينفذه الكمبيوتر وفي أي سيناريو ممكن تحصل مشكلة أو حدث غير متوقع ودا بيكون استثناء للسيناريو اللي يعرفه.
في الحالة دي الكمبيوتر مش هيعرف يتصرف وهيعمل Program Crash وعشان نتفادى دا لازم نعلم الكمبيوتر إزاي يتعامل مع الاستثناءات دي.
ال Exceptions أو الاستثناءات دي في ال Java بتنقسم ل 3 أنواع:
الـ Checked Exceptions
النوع دا من ال Exceptions بيتم فحصه والتأكد من عدم وجوده في ال Compile time وهنا ال Java Compiler بيديك تحذير من وجوده وبيقولك اعمله handle بدل ما يوقعلنا البرنامج. ومن أشهرها الـ IOException, SQLException
الـ Unchecked Exceptions
ودي Exceptions أسوء من ال checked لسببين:
مبنعرفش بوجودها غير في وقت تشغيل البرنامج فعلاً ولذلك بتكون كلها من نوع Runtime Exceptions
ال Exceptions دي بتكون نتيجة لأخطاء برمجية, يعني المبرمج كان ممكن يتفادها ويحلها لو بستخدم Good Programming Practices بس دا محصلش والجافا مشهورة بال Null pointer exception الناتج من محاولة تنفيذ عملية علي Object غير موجود, واللي ببساطة بيتحل لو المبرمج عمل تأكيد على وجود ال object قبل ما ينفذ عليه أي عملية هتؤدي لهذا ال Exception.
ومن أشهرهم كذلك:
الـ ArithmeticException
الـ IllegalArgumentException
الـ IndexOutOfBoundsExceptions
الـ Errors
هنا ال Errors بتشير للأخطاء اللي بتحصل خارج نطاق البرنامج بتاعنا ولكنها بتؤدي في النهاية انه يحصله crash و من أشهرها ال Out of memory Exception و Stack overflow Exception
API Authentication Methods
أثناء تعاملنا مع ال APIs بنحتاج نعمل User Authentication واللي هي عبارة عن عملية التحقق من هوية المستخدم اللي باعت ال Request, ودا جانب هام جدُا في حماية الـ API وكذلك خصوصية وأمان المستخدمين.
فورقة وقلم و تعالوا نتعرف على أشهر 5 طرق من ال User Authentication Methods. 🚀
Basic Authentication
دا أبسط نوع وفيه بنبعت اسم المستخدم وكلمة المرور في ال Request في صيغة Base64 , طبعًا النوع دا منخفض الأمان ومش بنستخدمه في الـ Production Environment إلا علي HTTPS Connection, لأن ال Base64 Encoding بيتحل بأي Decoder على الإنترنت فلو ال Eequest اتعرض ل Eavesdrop Attack يقدر المهاجم بسهولة يعرف بيانات المستخدم.
الاستخدام المناسب:
مناسب للاستخدام في وقت التطوير أو الـ Testing
ممكن نستخدمه في التطبيقات الداخلية واللي ضامنين إنها على شبكة آمنة.
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=API Key Authentication
ال API Keys عبارة عن مفاتيح أو "رموز تعريف" بيصدرها ال API لل Clients ودور ال Client أنه يبعتها مع كل Request لل API كوسيلة تحقق من هوية المستخدم. ال Client ممكن يبعتها ك Query String أو يحطها في ال Request Header أو حتي ك Cookie.
وزي ال Basic Authentication لازم نستخدمه علي HTTPS Connection لأن لو أي حد عرف ال API Key هيقدر ينتحل شخصية ال Client ويستعمل ال API باسمه.
الاستخدامات المناسبة:
بتكون في بيئات التطوير و الاختبار أو في التطبيقات الداخلية
ممكن نستخدمه في الـ Production ولكن مع وسائل أخري نزود بيها معامل الأمان.
ونلاحظ واحدة من أهم عيوب الـ API Key إنه مش بيدي User-Specific Permissions لأنه مصمم بالأساس عشان يستخدم بين ال Apps أو ال Services وبعضها.
مشاركة من أحمد عطية في مجتمع اقرأ-تِك 😂
JavaScript vs JavaScript The Good Parts
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم الـ 20% وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات بـ 50 جنيه بس 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال الـ WhatsApp Business أو من خلال الرسايل على مواقع التواصل الاجتماعي أو من خلال البريد الالكتروني contact@eqraatech.com 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
