Meitix

یه چیزی که خیلی وقتا توی دنیای تکنولوژی درباره‌اش صحبت می‌کنیم، بحث availability یا همون در دسترس بودن سیستمه. حالا اگه یه اپلیکیشن داری، سوال اینه که کاربرات چه درصدی از زمان می‌تونن ازش استفاده کنن؟
اینجاست که بحث اون ۹۹ درصدای معروف میاد وسط.

🔸۹۹٪
یعنی توی یه سال، سیستم حدود ۳.۶۵ روز خوابیده. یه چیزی شبیه اینترنت خونت که بیشتر وقتا کار می‌کنه ولی بعضی وقتا وسط کار می‌خوابه.

🔸۹۹.۹٪

اینجا سیستم حدود ۸.۷ ساعت توی سال داون میشه.

🔸۹۹.۹۹٪

حالا داریم وارد حرفه‌ای‌ها میشیم. داون‌تایم سالیانه میشه فقط ۵۲ دقیقه. سیستم خیلی خفن و قابل اعتماده. مثل سرورایی که بانک‌ها استفاده می‌کنن.

🔸۹۹.۹۹۹٪

یعنی یه داون‌تایم ریز در حد ۵ دقیقه توی سال. اینجا دیگه سیستم شبیه ساعت سوئیسیه.😅 هر لحظه کار می‌کنه.

🔸۹۹.۹۹۹۹٪

این سطح خدای availability حساب میشه! داون‌تایم در حد ۳۱ ثانیه توی ساله. اینو بیشتر شرکتایی دارن که اگه حتی یه لحظه داون بشن، ضررشون میلیونی یا میلیاردیه. مثل سیستم‌های پرداخت آنلاین.

کلا توی دنیای امنیت میگن؛ امنیت یه سد نباید باشه و لایه های مختلف امنیت باید وجود داشته باشه.

یه اصل وجود داره به اسم دفاع در عمق یا defence in depth

چندتا کوت جالب در موردش :

"Defense in depth is not about building an impenetrable wall but about creating a series of obstacles to deter, delay, and detect attackers"

یا

"A single line of defense is a single point of failure. Defense in depth ensures resilience by design."

چرا Salt واسه هش کردن رمز مهمه؟

فرض کنیم یکی دیتابیس سایت رو هک کنه و برسه به هش‌های رمز عبورها. اگه از salt استفاده نکرده باشیم، هکر با یه لیست آماده از پسوردای معروف (مثلاً یه فایل ۴ گیگی!) می‌تونه خیلی راحت هش‌ها رو تطبیق بده و رمز کاربرا رو پیدا کنه(rainbow table attack). حالا این وسط salt چی کار می‌کنه؟

یه مثال ساده:
رمز کاربر ۱: password123
رمز کاربر ۲: password123

اگه از salt استفاده نکنیم، هش هر دوتا کاربر عین هم می‌شه و هکر راحت با یه بار شکستن هش، به هر دوتا حساب دسترسی پیدا می‌کنه. ولی اگه یه مقدار salt تصادفی اضافه کنی:

رمز کاربر ۱: password123 + saltA
رمز کاربر ۲: password123 + saltB


حالا هش‌ها کاملاً متفاوت می‌شن، حتی اگه رمز کاربرا یکی باشه؛ ولی این همه اش نیست.
نکته اش اینه که هکر اذیت میشه برای پیدا کردن رمز

حالا چرا هکر اذیت می‌شه؟
هکر معمولاً یه لیست از پسوردای معروف داره که هش‌شون رو قبلا یه بار حساب کرده. ولی وقتی salt وارد بازی می‌شه:

1⃣ لیست آماده‌ش دیگه به درد نمی‌خوره، چون salt باعث می‌شه هش‌ها متفاوت بشن.

2⃣ مجبور می‌شه برای هر رکورد، همه پسوردای لیستش رو با اون salt محاسبه کنه یعنی به ازای هر رکورد باید اون ۴ گیگ فایل رو با salt دوباره حساب کنن. که معمولا نمیکنه و بیخیال میشه

خلاصه نمک یادمون نره🧂

ا owasp یه سری استاندارد امنیتی داره که برای داشتن برنامه امن باید رعایت کنیم.

1. Broken Access Control 🔓

وقتی یه نفر نباید به چیزی دسترسی داشته باشه، ولی می‌تونه سرک بکشه.
مثال: توی یه سایت خرید، شما نباید بتونید سفارش‌های بقیه رو ببینید، ولی اگر لینک سفارش کسی رو داشته باشی و بدون رمز باز بشه، این یه مشکل کنترل دسترسیه.



2. Cryptographic Failures 🔐

وقتی اطلاعات حساس درست قفل نشده باشه.
مثال: سایتی که اطلاعات بانکی شما رو ساده ذخیره کنه (مثلاً: 1234 5678 9012 3456) یا به جای HTTPS از HTTP استفاده کنه.



3. Injection 💉

وقتی هکر بتونه کدهای خودش رو بفرسته توی برنامه شما و اجراش کنه. مثل حملات sql/ shell injection


4. Insecure Design 🏗️

وقتی از اول سیستم رو اشتباه طراحی کرده باشی و امنیت توش لحاظ نشده باشه.
مثال: اپلیکیشنی که پسوردهای کاربرا رو بدون محدودیت طول و پیچیدگی قبول می‌کنه، مثل اینکه یکی پسوردش رو 1234 بذاره.



5. Security Misconfiguration ⚙️

وقتی تنظیمات سایت یا سرور درست انجام نشده باشه.
مثال: یه وب‌سایتی که به همه اجازه بده فایل‌های سرورش رو ببینن (مثلاً /config/settings رو باز کنی و اطلاعات حساسی ببینی).



6. Vulnerable and Outdated Components 🧩

وقتی از نرم‌افزارها یا کتابخونه‌های قدیمی استفاده کنی که مشکل امنیتی دارن.



7. Identification and Authentication Failures 🔑

وقتی سیستم درست کاربر رو تشخیص نمی‌ده یا روش لاگینش امن نیست.
مثال: سایتی که پس از چند بار تلاش اشتباه برای لاگین، حساب رو قفل نمی‌کنه و هکر می‌تونه هزار بار امتحان کنه تا رمز رو حدس بزنه.



8. Software and Data Integrity Failures 🛠️

وقتی داده‌ها یا به‌روزرسانی‌ها امن نیستن و قابل تغییرن.
مثال: یه اپلیکیشن که آپدیت‌های خودش رو از منابع غیرقابل اعتماد بگیره و هکر بتونه تو اون آپدیت کدهای مخرب بذاره.


9. Security Logging and Monitoring Failures 📋

وقتی سیستم نتونه اتفاقات مشکوک رو ثبت و پیگیری کنه.
مثال: هکری که وارد سایت بشه و کسی متوجه نشه چون سیستم ثبت وقایع نداره.


10. SSRF 🕵️

وقتی هکر سرور رو مجبور کنه که به جای اون، درخواست ارسال کنه.
مثال: کاربر باید URL تصویر را وارد کند: https://example.com/image.jpg.

هکر به جای URL معمولی، یک آدرس داخلی وارد می‌کند: http://localhost/admin.

چون این درخواست از طرف سرور میاد، ممکنه به اطلاعات حساس مثل پنل ادمین دسترسی پیدا کنه.

لاگ روتیشن

یه فایل لاگ داری که هر روز کلی اطلاعات توش میره و همش بزرگ و بزرگ‌تر میشه. بعد از یه مدت دیگه نه می‌تونی بخونی، نه می‌تونی ازش استفاده کنی!

اlog rotation یعنی به طور خودکار این فایل‌های لاگ رو تقسیم کنیم. مثلاً روزانه یا هفتگی یه فایل جدید درست می‌کنیم و قدیمیا رو آرشیو می‌کنی. چرا؟ چون:

سرعت کم میشه و پیدا کردن لاگی که میخوای سخت میشه

توی کانفیگ فایل های داکر میشه dns هم ست کرد. برای دانلود پکیج ها تحریم شده کار رو در میره. فایلشم اینجاست(نبود، باید ساخت)

Sudo vim /etc/docker/daemon.json

اندر فلسفه گو بخوایم بازم بگیم.

قضیهerrorه. گو میگه ارور ها هم value هستن و باید programmed بشن و این وسط یه درس زندگی هم میده😢 میگه

Dont panic

(پنیک فقط برای موقع کرش کردن مناسبه)

مثلا لایه سرویس ما ممکنه یه خطای حساس بده ما باید چک کنیم که اگه خطای که برگشته فلان خطا بود یه چیز دیگه برگردون تا پیام حساس سمت کاربر نرود

جالبه گو به هر pkg ها به چشم layer نگاه میکنه و نه گروه پکیج ها؛ و دقیقا به همین mindsetه که جلوی cyclic dependencies رو میگیره.

فرق هندلر و سرویس چیه؟

هندلر: کاری که مستقیم با درخواست و پاسخ سر و کار داره. مثلاً از کلاینت درخواست می‌گیره (مثلاً یه کاربر جدید رو ثبت کن)، اطلاعات ورودی رو چک می‌کنه و بعد می‌ده به سرویس.

سرویس: منطق اصلی و سنگین برنامه تو این لایه‌ست. اگه یه حسابی قراره ساخته بشه یا دیتایی ذخیره بشه، کارش اینجاست انجام می‌شه.


یه مثال ساده:
هندلر: درخواست ساخت کاربر جدید رو از کلاینت می‌گیره، چک می‌کنه اسمش خالی نباشه، می‌ده سرویس.

سرویس: دیتا رو میگیره و چک میکنه کسی با این ایمیل ثبت نام نکرده باشه قبلا. دیتا رو تو دیتابیس ذخیره می‌کنه و اگه مشکلی باشه برمی‌گردونه.



چرا جداسازیشون مهمه؟
1. مرتب‌تر می‌شه کدتون: هر چیزی سر جای خودش قرار می‌گیره، هندلر با درخواست‌ها و سرویس با منطق.

2. تست کردن راحت‌تره: می‌تونید سرویس رو مستقل از هندلر تست کنید