امنیت
این فصل پوشش میدهد
- ملاحظات مهم برای ایمنسازی سازمان شما
- توسعه با نگاه امنیتی
- مدیریت بحران در میانه حمله یا رخنه
- تشخیص زمانی که یک CISO یا مدیر ارشد امنیت اطلاعات اختصاصی لازم است
امنیت از آن حوزههایی است که اگر درست انجام شود، بیزحمت و آسان به نظر میرسد. اما اگر بد انجام شود، مثلا فقط برای تیک زدن یک جعبه حداقل کار انجام شود، مزاحم میشود. برخی سازمانها در ظاهر امنیت عالی دارند، اما سطح را کمی بخراشید و میبینید از نظر دیجیتال کلید را زیر پادری گذاشتهاند. امنیت نیرویی فریبنده است؛ هرچه مدت بیشتری بدون حادثه بگذرانید، بیشتر میتوانید خودتان را قانع کنید که محیطی امن دارید، بیشباهت به اینکه فکر کنید خانهتان ضدآتش است چون تا امروز آتش نگرفته است.
تردیدی نیست که اضافه کردن امنیت در پایان کار زحمت زیادی میسازد و برای درست انجام شدن تمرکز و تلاش جدی میخواهد و اختلال زیادی ایجاد میکند. با این حال، حتی اگر از آغاز هیچ تلاش واقعی برای ساختن امنیت در پلتفرم نکرده باشید، میتوانید کارهای زیادی برای ایمن کردن یک پلتفرم موجود انجام دهید. در این فصل، برخی گامهایی را مرور میکنیم که میتوانید بردارید تا برای ساختن محیطی امن پیشرفت چشمگیری داشته باشید.
۱۲.۱ وصلهکردن
نرمافزار هرگز عاری از باگ نیست، مهم نیست چه کسی آن را توسعه داده باشد. باگها عمدا وارد یا ساخته نمیشوند؛ از چیزی پدید میآیند که به شکلی استفاده شده که هرگز برایش فکر یا تست نشده بود. مشکلات میتوانند بیخطر باشند، مثلا چیزی درست رندر نشود، یا بسته به محیط بالقوه مرگبار باشند. وقتی یک باگ شناسایی شد، مطمئن باشید کسی راهی برای بهرهبرداری کردن آن برای نوعی مزیت، عمل پلید، سود یا حتی فقط حق پز دادن پیدا خواهد کرد.
بنابراین، بیشتر مسائل امنیتی از یکی از سناریوهای زیر سرچشمه میگیرند:
- کدی که ضعیف توسعه یا تست شده است
- ویژگی خوشنیتی که اثر جانبی پیشبینینشدهای داشته است؛ مثلا کتابخانه لاگگیری در Apache Log4j در اواخر ۲۰۲۱ که جلوتر توضیح داده میشود
در چشمانداز رایانش مدرن امروز، بیشتر سازمانها وقتی باگ یا حفره امنیتی توسط تیم داخلی کشف یا از بیرون گزارش میشود، در ارائه اصلاح یا وصله بسیار واکنشی عمل میکنند. هیچکس نمیخواهد وقتی پای مسائل امنیتی وسط است انگشت اتهام به سمت او تکان داده شود.
کلید کار این است که سازمان خود را با وصلهها بهروز نگه دارید و اجازه ندهید خیلی عقب بیفتید. برای مؤثر بودن این کار، به راهبردی دوشاخه نیاز دارید:
- شناسایی وصلهها و فایلها
- زمانبندی بهروزرسانی
۱۲.۱.۱ شناسایی وصلهها
نخستین چیزی که باید بدانید فهرست همه نرمافزارها، شامل کتابخانهها، و نسخههایی است که در سازمان خود اجرا میکنید. در فصل مستندسازی نیاز و سازوکار این فهرست را پوشش دادیم، چون به نیازهای زیادی خدمت میکند. نداشتن فهرست بهروز شما را در معرض خطر از دست دادن یک وصله حیاتی قرار میدهد؛ ممکن است بهسادگی آن را کنار بگذارید و فکر کنید به شما مربوط نیست.
نخستین جایی که باید برای بهروزرسانی نگاه کنید، سایت فروشنده است. همه فروشندگان بزرگ نرمافزار صفحه وب یا فهرست ایمیلیای دارند که میتوانید زیر نظر بگیرید. پروژههای متنباز یادداشتهای انتشار و انجمنهایی دارند که بهراحتی میتوانید مشترک کنید. برای هشدارهای امنیتی، بهترین منبع رجیستری شناختهشده CVE است.
۱۲.۱.۲ زمانبندی
دانستن اینکه چه چیزی باید بهروزرسانی شود احتمالا بخش آسان کار است. حالا باید بفهمید چه زمانی آن را اعمال کنید. وسوسه این است که برخی بهروزرسانیها را نامرتبط بدانید و کنار بگذارید. اشتباه بزرگ. وارد آهنگ منظم دستکم ماهانه شوید؛ بهروزرسانیهای کوچک و مکرر که در کوتاهمدت اثرشان را کنترل میکند اما در بلندمدت شما را محافظتشده نگه میدارد. ایدهآل این است که راهاندازیای شبیه استقرار آبی-سبز، که در فصل ۹ دیدیم، داشته باشید تا تست وصله یا بهروزرسانی پیش از ثبت کردن آن آسان باشد.
اکثریت بسیار بزرگی از بهروزرسانیها، بهویژه از منابع معتبر، ۹۹٪ مواقع بینقص کار میکنند. هرچقدر این احتمال خوب باشد، نمیتوانید فرض کنید همیشه شما را پوشش میدهد. تست، تست، تست. از محیط توسعه یا آمادهسازی برای تست وصله استفاده کنید، یا دستکم آن را در بهروزرسانیهای دورهای خود بگنجانید. به این ترتیب، تیم تست شما میتواند هر مورد عجیب را در بخشی از فرایند بگیرد.
برای سیستمهایی که راهاندازی محیطی ندارند، عملا باید با مهمات واقعی بازی کنید: بهروزرسانی تولید. سیستمهای بکآفیس، مثل ایمیل و سرورهای فایل، در این دستهاند. در این وضعیتها، بهروزرسانی خارج از ساعت کاری همیشه ترجیح دارد؛ ایدهآل شنبه، تا اگر واقعا چیزی خراب شد، یک روز اضافه، یکشنبه، برای حل مسئله وجود داشته باشد.
۱۲.۱.۳ ملاحظات ویژه
سختافزارهایی مثل چاپگر، اسکنر و TV معمولا زیر چتر CTO قرار نمیگیرند، اما اینها هم سیستمهایی هستند که به پایش مداوم برای بهروزرسانیهای امنیتی نیاز دارند. سختافزارهای مدرن، مثلا محصولات Chromecast/Nest گوگل، بهطور معمول خودکار بهروزرسانی میشوند. با این حال، همه تولیدکنندگان به این سختگیری نیستند. مسیریابها و سوئیچهای شبکه به توجه اضافه نیاز دارند، و گاهی آشکار نیست بهروزرسانیها چه زمانی موجودند.
برخی دستگاهها نیاز دارند کسی دستی وارد کنسول مدیریتیشان شود و بررسی کند. این گامی ارزشمند است و باید بخشی از وظایف مدیریت IT شما باشد. عادت کنید آخرین بررسی را در لاگ سراسری یا مدیریت دارایی ثبت کنید. هر دستگاهی که اتصال شبکه دارد باید مثل سیستم تولید رفتار شود؛ امنیت و مدیریت رمز عبور آن، هرقدر بیخطر به نظر برسد، به توجه شما نیاز دارد. هک میتواند از هر دستگاهی در شبکه شما وارد شود. فرض کنید اگر IP نشانی دارد، تهدید بالقوه است.
نکته: به همین دلیل، روش خوب این است که محیط تولید خود را در شبکهای کاملا جدا و ایزوله نگه دارید. به اشتراک گذاشتن شبکه بکآفیس با شبکه تولید، سطح حمله شما را به دستگاههای ناشناختهای باز میکند که وارد شبکه میشوند و از آن خارج میشوند.
۱۲.۲ تست نفوذ
تست نفوذ، همانطور که از نامش پیداست، زمانی است که موجودیتی بیرونی تلاش میکند از بیرون وارد سیستم شما شود و دنبال سوراخها یا ترکهایی میگردد که بتواند برای ورود یا ایجاد اختلال بهرهبرداری کند. از میان همه تستهای امنیتی، این فرایند یکی از بزرگترین مسائل دارونما را دارد: خیلی وقتها شرکتها با گواهی تست نفوذ خود احساس آرامش میکنند، فقط بعدا میفهمند بیش از شش ماه از آن گذشته است.
بهمحض اینکه تست نفوذ شما تمام میشود، از تاریخ گذشته است. هکها پیوسته تکامل مییابند و هرگز نباید فقط چون یک تست را گذراندهاید فرض کنید نفوذناپذیرید. نکته دیگر اینکه دفعه بعد که انتشار نرمافزاری انجام میدهید، همه تستهای نفوذ تاریخی بیاعتبار میشوند. چرا؟ چون نمیدانید این انتشار نقص یا سوراخ تازهای در دفاعها آشکار کرده یا نه. بنابراین، تست نفوذ نباید رویدادی یکباره یا دورهای باشد. باید بخشی پیوسته، جاری و یکپارچه از پیوسته استقرار شما باشد.
یک تست نفوذ خوب در لایهها کاوش میکند. مثلا واضحترین تست از سمت عمومی است. اما یکی از کارکنان شما که حقهای ارتقایافته دارد، به چه دسترسی یا شیطنتی میتواند برسد؟ اینها سطحهای بعدی تست امنیتاند که اغلب نادیده گرفته میشوند.
میتوانید تستهای نفوذ متنباز زیادی به زرادخانه امنیتی خود اضافه کنید، اما فقط به یکی تکیه نکنید، بهویژه اگر بهروزرسانی نمیشود. اگر بتوانید سربار بودجهای اضافه را توجیه کنید، از سرویس شخص ثالث استفاده کنید؛ بهخصوص اگر مسئول مدیریت داده حساس، مانند داده مالی یا سلامت، هستید.
۱۲.۳ مهندسی اجتماعی
بیشتر افراد درباره مهندسی اجتماعی شنیدهاند: توانایی قانع کردن کسی داخل شرکت برای انجام کاری که به مهاجم امکان ورود میدهد، در حالی که قربانی بیچاره باور دارد هیچ کار اشتباهی نمیکند و حتی شاید از کمک به کسی که به نظر نیازمند است رضایت شخصی بگیرد.
نمونه خوب این بهرهبرداری تماس با خط پشتیبانی است؛ مهاجم شخص پشتیبانی را قانع میکند که فردی است که نیست، و بنابراین به داده حساس دسترسی پیدا میکند. ممکن است به بیگناهی تلاش برای ورود به ساختمان اداری باشد؛ عبور از بازکردن در با کلید امنیتی از طریق راه رفتن نزدیک پشت سر کسی، در حالی که آن شخص به احتمال زیاد در را باز نگه میدارد. فردی با اعتمادبهنفس میتواند با رفتار کردن انگار به آنجا تعلق دارد، راه زیادی برود.
اگرچه برجسته کردن چنین مواردی وقتی روی کاغذ نوشته میشود آسان است، در دنیای واقعی کاملا متفاوت است؛ وقتی حفاظها پاییناند و غریزه طبیعی انسان برای خوشایند بودن و کمک کردن فعال میشود.
۱۲.۴ نشت داده
درست مثل لوله ترکخورده یا شیر زنگزدهای که آب نشت میدهد، سازمان شما هم میتواند داده را در بستههای کوچک نشت دهد؛ بستههایی که در ظاهر بیضررند، اما اگر کنترل نشوند میتوانند حوزه بزرگی برای حمله امنیتی بسازند.
تشخیص نشت داده از دیدن شیر چکهکنندهای که گودالی از آب میسازد بسیار سختتر است؛ نمیتوانید به صدای چکه یا پاشش گوش دهید. نشت داده به تلاش متمرکز و هوشیاری مداوم نیاز دارد. برقراری توازن میان دسترسی و امنیت کاری دشوار است. با دقت فکر کنید چه چیزی برای سازمان شما مهم است و محافظs را پیرامون همان حوزهها بسازید. نشت داده میتواند در عجیبترین جاها ظاهر شود. بیایید چند حوزه را که منابع رایج نشت هستند ببینیم تا فکر کنید در کجای سازمان شما ممکن است گودال داده در حال شکلگیری باشد.
۱۲.۴.۱ لاگگیری
اگر فعالانه اطلاعات را لاگ میکنید، و چرا نکنید، لاگهای شما گنجینهای از اطلاعات مفید برای اشکالزدایی و پروفایلگیری هستند. همه چیز خوب است. اما صبر کنید؛ توسعهدهندگان شما دقیقا چه چیزی را داخل آن عبارتهای لاگ میریزند؟
اگر API درخواستها و پاسخها را لاگ میکنید، که باز هم بسیار رایج است، با داده حساس موجود در آن فراخوانی API چه میکنید؟ شما تلاش زیادی میکنید مثلا شمارههای تامین اجتماعی یا اطلاعات گواهینامه رانندگی را ذخیره و رمزگذاری کنید، فقط برای اینکه این داده چون در بار پیام یک API ظاهر شده در مخزن لاگ پایان یابد.
۱۲.۴.۲ خطاهای برنامه
آیا تا به حال از صفحه وبی بازدید کردهاید و به جای صفحه مورد نظر، صفحه خطا گرفتهاید؛ گاهی پر از داده اشکالزدایی برای کمک به توسعهدهنده در تشخیص مشکل؟ با این حال، شما توسعهدهنده نیستید؛ فقط عضوی از عموم هستید که مرور میکند.
چنین لاگهای «کمککنندهای» میتوانند داده حساس زیادی درباره اتصالهای پایگاه داده و سایر دادههای محیطی داشته باشند. خراب کردن کردن یک وبسایت میتواند سرنخهای بزرگی برای هکرهای بالقوه تولید کند.
در روزهای قدیم، وبسایتهایی که با JSP، CFML و PHP نیرو میگرفتند، در صفحه شکستخورده ردیابی پشته کامل و هرچه در حافظه سرور بود تخلیه میکردند. این اطلاعات هرگز برای تولید طراحی نشده بود، اما جایی در مسیر، هنگام خروج از محیط توسعه/تست، آن گزینه خاموش نشده بود. اگرچه این وضعیت امروز نادر است، لاگهای خطا اگر کنترل نشوند میتوانند داده زیادی نشت دهند.
۱۲.۴.۳ خروجیهای داده
سازمان شما ممکن است به کاربران اجازه دهد داده برونبری کنند یا پرسوجوها یا تحلیلها خود را از طریق رابط یا حتی API اجرا کنند. آیا داده بیش از حد در اختیار کاربر نهایی گذاشته میشود؟
خیلی وقتها ابزار هوشمندی کسبوکار یا گزارشدهی اگر داده درست قفل نشده باشد، بهقدر کافی بیگناهانه داده نشت میدهد. چیزی که روی صفحه رندر میشود شاید فقط زیرمجموعهای از دادهای باشد که واقعا برگشته است، و یک بررسی سریع در کنسولهای توسعهدهنده مرورگر داده بسیار بیشتر، و شاید ارزشمندتری، نشان میدهد.
۱۲.۴.۴ کنترل نسخه
کد قلب بسیاری از سازمانهاست، اما میتواند منبعی واقعی و به معنای تحتاللفظی برای داده حساس باشد. اعتبارنامههایی مثل نام کاربری/رمز عبور برای سرویسها که ثبت میشوند، ممکن است در جاهای ناخواسته گوناگون پایان یابند؛ مثلا ابزارهای کیفیت کد که بازرسی انجام میدهند و برای عملکرد و تحلیل نسخه خود را میسازند. برخی ابزارهای تجاری یا متنباز نسخهبندی مثل GitHub بررسی ابتدایی انجام میدهند و هشدارهایی میفرستند که توضیح میدهد چه یافتهاند.
۱۲.۵ چرخش رمز عبور
رمزهای عبور هنوز احرازگر انتخابی برای بیشتر سیستمهایی هستند که باید با آنها تعامل کنیم. رمزهای عبور ذاتا بد نیستند. جایی که بدنام میشوند در تولید و مدیریتشان است. رمز عبوری که هرگز تغییر نمیکند و سختکدشده است دیگر نقش امنیتیای ایفا نمیکند؛ فقط ویژگی پیکربندی اضافهای است.
راهبرد خوب رمز عبور باید راهبردی باشد که در آن خود رمز عبور طول و پیچیدگی کافی داشته باشد، ترکیبی از نویسهها و نمادها، و بتواند بدون پیامد زیاد بهراحتی تغییر کند. رمزهای عبوری که باید سختکدشده شوند یا در فایلها قرار بگیرند تا استفاده شوند مشکلساز خواهند شد. اگر رمز عبور در فایل باشد، هر کسی که به سیستم فایل محل فایل دسترسی دارد میتواند آن را بهراحتی بخواند.
غیرمعمول نیست، بهویژه در برخی سیستمهای قدیمیتر، که اعتبارنامههای پایگاه داده در فایل XML باشند و اگر تغییر کنند، راهاندازی دوباره سرور لازم شود. بسیاری از سرورهای برنامه از این نقص رنج میبرند. در چنین وضعیتهایی، تغییر رمز عبور به کابوس لجستیکی بهروزرسانی کردن فایلها، راهاندازی دوباره سرورها و آنلاین آوردن دوباره چیزها به شکلی زمانبندیشده تبدیل میشود. جای تعجب نیست که رمزهای عبور بهندرت تغییر میکنند.
رمزهای عبور باید موجوداتی زنده باشند و اگر لازم شد بتوانند مرتب تغییر و بهروزرسانی شوند. نرمافزاری که به رمز عبور نیاز دارد باید بتواند آن را در زمان واقعی از مدیر رمز عبور یا مدیر امنیت درخواست کند. ارائهدهندگان ابر همگی چنین سرویسهایی دارند که پایه یک برنامه ابرزاد قوی را تشکیل میدهد؛ نه اعتبارنامه محلی و نه اعتبارنامه دوردست تا زمان آغاز اتصال شناخته نمیشود.
اما احتمال دارد لازم باشد در دنیایی ترکیبی زندگی کنید و رمزهای عبور را دستی در فایل ایستا نگهداری کنید، حتی اگر فایل بهطور امن با اسکریپت تولید شده باشد. بنابراین باید همه حوزههایی را که به ترکیب نام کاربری/رمز عبور نیاز دارند شناسایی کنید و برای هر حوزه، رویه سیاست تغییر را توضیح دهید: چه چیزی باید تغییر کند و چه چیزی راهاندازی دوباره شود.
یک صفحهگسترده ساده، کنار موجودی سیستمهای شما، میتواند همه سیستمهایی را که به اعتبارنامه نیاز دارند ردیابی کند، همانطور که در این جدول نشان داده شده است.
| حوزه | نرمافزار | قالب | نیاز به راهاندازی دوباره | هدف |
|---|---|---|---|---|
| پایگاه داده وب | Tomcat | web.xml | بله | ردیابی اعتبارنامههای سیستم |
چرخش اعتبارنامهها را در این زمانها در نظر بگیرید:
- کارمندی سازمان را ترک میکند
- رخنه امنیتی مشکوک رخ میدهد
- نرمافزار بهروزرسانی میشود
- زمان بهروزرسانیهای دورهای رسیده است، مثلا هر ماه
منضبط کردن تیم و تمرین چرخش رمز عبور ترس و عدم قطعیت را از فرایند بیرون میکشد. یک توصیه کلی: اگر چرخش انجام میدهید، آن را در کل مجموعه انجام دهید. اگر گمان میکنید یک یا دو اعتبارنامه در معرض نفوذ قرار گرفتهاند، فرض کنید همه در خطرند. در برابر میل به انجام فقط موارد انتخابی مقاومت کنید.
۱۲.۶ محیط امن
امنیت ویژگی نیست، چیزی نیست که اضافه کنید یا بخرید. در عوض، امنیت فلسفه و مجموعهای از اصول است که با آن زندگی و کار میکنید و حوزهای است که پیوسته زیر نظر دارید. ایجاد محیط امن حول سه اقدام پایه میچرخد: شناسایی، حفاظت و پایش.
۱۲.۶.۱ شناسایی
پیش از نصب «حصار» درست، باید حوزههایی را که باید محافظت کنید بشناسید. این را «سطح حمله» مینامند و همه مسیرهای ممکن را تعریف میکند که حمله یا نشت بالقوه میتواند از آن رخ دهد. بهعنوان CTO، کار شما این است که سطح حمله را تا حد ممکن کاهش دهید و وقتی نمیتوانید، آن را تا حد ممکن امن کنید. نمونههایی از سطح حمله در سازمان شما، همراه با راههایی برای کاهش آن، عبارتاند از:
- سرورهای تولید در همان فضای شبکهای سرورهای توسعه اجرا میشوند. افراد زیادی به آن دسترسی دارند. سطح حمله را با قرار دادن تولید در شبکه جداافتاده کاهش دهید.
- اعتبارنامههای مشترک برای پایگاه داده هیچ پاسخگویی یا توانایی حذف یک فرد مشخص ایجاد نمیکند. سطح حمله را با دادن نام کاربری و رمز عبور اختصاصی فقط به کسانی که نیاز دارند کاهش دهید.
اینها نمونههایی واقعیاند که برای ایجاد اثر چشمگیر به تغییرات عظیم و فراگیر نیاز ندارند. یافتن همه سطحهای حمله شما تمرینی یکباره نیست. هر بار انتشار جدید مستقر میشود یا سرویس تازهای معرفی میشود، سطح حمله شما تغییر میکند و باید دوباره ارزیابی کنید که دفاعهای فعلی کافیاند یا نه.
۱۲.۶.۲ حفاظت
پس از شناسایی همه حوزههایی که بالقوه در خطرند، گام منطقی بعدی حفاظت از آنهاست. این دشوارترین بخش فرایند است. هر لایه حفاظت هزینهای دارد؛ هم مالی و هم از نظر اصطکاک احتمالی برای کاربر. سناریوی زیر را برای دسترسی به پایگاه داده، یا هر سیستم احرازشده، در نظر بگیرید:
- بدون نام کاربری یا رمز عبور
- نام کاربری یا رمز عبور مشترک
- نام کاربری یا رمز عبور فردی
- دسترسی VPN برای رسیدن به پایگاه داده
- MFA یا احراز هویت چندعاملی، بهعلاوه VPN و نام کاربری و رمز عبور فردی
با معرفی هر لایه، هزینه بیشتری برای مدیریت فرایند، زمان و ویژگیها و مجوزهای اضافه ایجاد میشود. در عین حال، هر لایه اصطکاک یا حلقههای بیشتری برای کاربر ایجاد میکند.
این بدهبستانی است که هنگام محافظت از سیستمها با آن روبهرو هستید. امنترین پایگاه داده، مثلا، پایگاه دادهای است که به شبکه وصل نیست و هیچکس هیچ دسترسیای به آن ندارد. هرچند این از نگاه امنیت جذاب است، برای کسبوکار کاملا غیرعملی است. داده باید قابل دسترس باشد تا برای کسبوکار ارزش و بینش فراهم کند. پیدا کردن توازن میان امنیت و دسترسی برای هر سیستم متفاوت خواهد بود و نیاز به بررسی و سپس مشورت با کسبوکار دارد تا همه فرایندها و سیاستها را بپذیرند.
همانطور که ضربالمثل قدیمی درباره تعداد راههای جدا کردن پوست گربه میگوید، امنیت هم همینطور است. حفاظت در لایههای بسیار میآید و بزرگترین اشتباه، یا فرض، این است که یک لایه را معادل امن بودن بدانید.
در عوض، به لایههای متعدد فکر کنید که هرکدام حوزههای متفاوتی را محافظت میکنند. این اغلب به مدل پنیر سوئیسی معروف است. مزیت بزرگ این مدل این است که به دفاع یک سازوکار تکیه نمیکند. نمونهای از آن دیوار آتشی است که همه درگاهها جز چند درگاه محدود را میبندد و فقط کاربران را وارد زیرشبکه شبکهای میکند که بهعنوان شبکه سنگر برای دسترسی عمیقتر عمل میکند. حفاظتهای سختافزاری همراه با چنین نرمافزاری میتوانند نیرویی قدرتمند بسازند.
۱۲.۶.۳ پایش
پس از شناسایی و برداشتن گامهایی برای حفاظت، مرحله بعدی و نهایی پایش مداوم برای حملات و رخنههاست، اگر کسی توانست از دفاعها عبور کند. این هدف دوگانه دارد: نخست، اطمینان از اینکه دفاعهای فعلی هنوز سالم و در حال کارند. هیچ چیز بدتر از این نیست که پس از reboot بفهمید نرمافزار دیوار آتش درست بالا نیامده است. دوم، پیدا کردن حوزههای ضعیفی است که میتوانند محکمتر شوند. مهاجمان همیشه تکنیکهای خود را تکامل میدهند و هدف شما این است که مطمئن شوید تیم و دفاعهایتان دستکم یک قدم جلوترند.
منبع رایج این پایش، لاگهای خروجی هر لایه حفاظتی است. گفتنش از انجام دادنش آسانتر است. در واقعیت، هر لایه یا نوع کنسول یا لاگ فایل خودش را دارد. اینکه کسی وارد هر سیستم شود و بررسی کند کاملا غیرعملی است. خستگی انسانی بالاخره رخ میدهد و چیزها شروع به از دست رفتن میکنند.
آنچه لازم است راهی برای گرد آوردن همه لاگهای مختلف در یک تجمیعکننده واحد است تا بتوان آنها را در سطحی جامع پایش کرد. این نمای کلی اجازه میدهد چیزی را ببینید که در ظاهر نامرتبط است اما در واقع بخشی از حملهای هماهنگ را تشکیل میدهد.
پیچیدگی این داشبورد تا حد زیادی به بودجه و ارزش چیزی که محافظت میشود بستگی دارد. مثلا ابزاری مانند Elasticsearch یا Splunk، تجمیعکنندههای شناختهشده لاگ، شروعی عالی است. برخی ابزارهای بسیار پیشرفته با استفاده از هوش مصنوعی، لاگهای دریافتشده را پیوسته تحلیل میکنند.
هر مسیری که میروید، و این مسیر تکاملی است، مطمئن شوید نظم لازم را برای نگاه مداوم به چیزها ایجاد میکنید. به هیچ حفاظتی که گذاشته شده تکیه نکنید و فرض نکنید همه کاری که باید انجام دهید همان است. این بخشی جاری و اصلی از وظایف تیم شماست.
ارزش اشاره دارد که این تجمیع بخشی از فرایند ممیزی شماست. حوزهای که گاهی نادیده گرفته میشود، ثبت و لاگ کردن ورودها، چه موفق و چه ناموفق، است. افزودن این سطح جزئیات به شما اجازه میدهد فعالیت غیرمعمول را مشاهده کنید؛ مثلا استفاده از حساب یک کارمند در نیمهشب یا تلاش برای دسترسی به حسابی که تازه بسته شده است. سطح جزئیات به سازمان شما و نوع دادهای که تحت نگهبانی شماست بستگی دارد.
۱۲.۷ توسعه با امنیت
برای سازمانهایی که کد توسعه و مستقر میکنند، دو حوزه زیر به ملاحظات امنیتی مشخص نیاز دارد:
- اقدامهای امنیتی درون کد توسعهیافته
- امنیت در خط لوله ساخت و استقرار
۱۲.۷.۱ ساختن کد امن
توسعه کد امن سخت است. اگر آسان بود، لازم نبود مدام نرمافزار را وصله و بهروزرسانی کنیم. کد به دو دلیل اصلی آسیبپذیر میشود:
- کدنویسی ضعیف یا باگی که فرصتی برای بهرهبرداری پلید ایجاد میکند
- ویژگیهای خوشنیتی که به دلیل پیچیدگی خود سوراخهای ناخواسته ساختهاند
زبانهای مختلف روشهای خاص خود را دارند که در آن کدنویسی ضعیف میتواند اثر بگذارد. زبانهایی که از توسعهدهنده میخواهند حافظه را خودشان مدیریت کنند، نسبت به زبانهایی که حافظه در آنها خودکار مدیریت میشود، ریسک بیشتری برای حملات سرریز حافظه دارند. نمونه دیگر تزریق SQL معروف است؛ جایی که یک عبارت پایگاه داده با انتخاب هوشمندانه مقدار اول میتواند به چند عبارت تبدیل شود.
تزریق SQL: یک توضیح
وبسایتی را در نظر بگیرید که قابلیت جستوجو ارائه میکند و به کاربر اجازه میدهد نامی را برای جستوجو وارد کند. شاید کدی که به پایگاه داده دست میزند شبیه زیر باشد:
stmt = “SELECT id, email FROM table X WHERE name='” + inputFromUser + “'“;بیگناه به نظر میرسد، درست؟ اما با بررسی دقیقتر، توسعهدهنده اینجا حفره امنیتی عظیمی ساخته که ممکن است اجازه دهد کل پایگاه داده در معرض نفوذ قرار گیرد یا حتی حذف شود. چگونه؟
اگر به جای تایپ noah در جعبه جستوجوی فرانتاند، کاربر تایپ کند '2'; TRUNC X;' و آن درخواست را به API بفرستد چه میشود؟ این عملا دو عبارت SQL جدا میسازد که یکی پس از دیگری اجرا میشوند، با فرض اینکه درایور اجازه دهد که بیشترشان میدهند. عبارت SQL اول دنبال نامی برابر ۲ میگردد و مشکلی ایجاد نمیکند. اما دومی، TRUNC X، همه ردیفهای جدول X را خالی میکند. پس از کمی آزمون و خطا، مهاجم میتواند در پایگاه داده ویرانی ایجاد کند.
به این حفره امنیتی فکر کنید: هکر حتی لازم نیست دسترسی شبکه ویژه یا دسترسی ارتقایافته به پایگاه داده بگیرد؛ فقط از همه مسیرهایی استفاده میکند که شرکت خودش ساخته است، از جمله UI تازهای که عبارت SQL آلوده را میپذیرد.
در روزهای اولیه وبسایتها، چنین حملاتی رایج بود و بسیاری کشف نمیشد. هرچند چنین سوراخهایی امروز نادرترند، توسعهدهندگان همچنان کد بدساخت میسازند، بهویژه کسانی که درباره کدنویسی امن درست راهنمایی یا آموزش نشدهاند و یاد نگرفتهاند اساسا به هیچچیزی که کاربر میدهد اعتماد نکنند. این فقط یک نمونه است. توسعه کد امن و بیباگ، رشتهای کامل در خود است و کتابهای زیادی برای کمک به این حوزه وجود دارد.
میتوانید با آموزش نگه داشتن تیم کدنویسی، داشتن استانداردهای کدنویسی و بازبینی کد گسترده ریسک را کاهش دهید. ابزارهای کیفیت کد مانند SonarQube میتوانند برخی مسائل استاندارد را بگیرند و همیشه تکامل مییابند، اما هرگز جای چشم انسانی باتجربه را نمیگیرند.
۱۲.۷.۲ امنسازی فرایند ساخت
حوزهای که معمولا سطح امنیت محیط تولید را ندارد، محیط توسعه است. در ظاهر میتوانید بفهمید چرا کمی آزادتر است؛ توسعهدهندگان در حال برش و آزمایش با کد و نرمافزارند، و امنیت با همه عظمت و مزایایش میتواند مزاحم شود.
با این حال، بسیاری از تیمها برای ساخت نرمافزار آماده استقرار از همان محیطی استفاده میکنند که برای تولید استفاده میشود. چه اقدامهایی انجام شده تا مطمئن شوید کتابخانه سرکش یا قطعه کد مخرب بیآنکه کسی متوجه شود اضافه نشده است؟
اگر خط لوله ساخت شما امن نباشد، برای کسی آسان خواهد بود تغییر کوچکی ایجاد کند. همینطور، اگر کنترل نسخه شما قفل نشده یا مدیر کتابخانه شما، مثلا Maven یا npm، امن نیست و نسخه کتابخانه قفل نشده، ریسک مستقر کردن کدای را دارید که شاید ندانید واقعا داخلش چیست.
این همانطور است که حمله مشهور SolarWinds رخ داد؛ حملهای که اثر عظیمی در انواع صنایع داشت، چون نرمافزار توسط سازمانهای بزرگ برای مدیریت زیرساخت IT استفاده میشد. هکرها اسب تروآ کامل را پیدا کردند: لازم نبود هر هدف را هک کنند، فقط یک نرمافزار مشترک را که همه در آن شریک بودند. سپس در بخشی از فرایند عادی بهروزرسانی نرمافزار، کد مخرب در عمق شبکهها توزیع میشد، بیآنکه زنگ خطری به صدا درآید.
امنترین ذهنیت این است که فرض کنید هر حوزهای در سازمان شما هدف بالقوه است و گامهای لازم را برای ساختن هرچه بیشتر حفاظتها بردارید. این شامل قرار دادن فرایند ساخت در محیطی جدا، قفل کردن شماره نسخه مشخص برای کتابخانههای شخص ثالث، ارتقا فقط وقتی خودتان تصمیم گرفتهاید و آنها را اعتبارسنجی کردهاید، و توجه به هر تغییر ناگهانی در اندازه فایل است که به تغییرات عمده کد نسبت داده نمیشود؛ مثلا استقراری که دو برابر اندازه معمول خود است باید زنگ خطر را روشن کند.
۱۲.۸ «ما تحت حمله هستیم»
یکی از بدترین کابوسهای شما لحظهای است که میفهمید تحت حمله هستید. دیگری، که بسیار نزدیک است، این است که ندانید تحت حمله هستید. امیدواریم این کمتر رخ دهد، با این فرض که همه گامهای لازم برای پایش بلادرنگ را برداشتهاید. حمله میتواند به شکلهای مختلفی وارد شود:
- حمله انکار سرویس
- داده در حال برونبری شدن
- داده در حال حذف یا رمزگذاری شدن
- کسی بیصدا فعالانه در سیستمهای شما حرکت میکند
این میتواند موقعیتی بسیار پرفشار باشد، اما کار مهم و البته بدیهی این است که وحشت نکنید. دیگران برای برنامهای سنجیده و مسئولانه به شما نگاه خواهند کرد. نخستین چیزی که باید تلاش کنید بفهمید حوزه حمله و راه محدود کردن خسارت بیشتر است؛ کاری که گفتنش بسیار آسانتر از انجامش است.
۱۲.۸.۱ کلید قطع
به جای اینکه تا وقوع حمله صبر کنید و بعد تصمیم بگیرید چه اقدامی انجام دهید، باید به سازمان خود نگاه کنید و مجموعهای از پاسخها یا کلیدهای قطع بسازید. اینها نسخههای دیجیتال دیوارههای آببند کشتیاند که نهتنها برای استحکام طراحی شدهاند، بلکه برای مهر و موم و جدا کردن شکاف بدنه نیز هستند تا یک سوراخ کل کشتی را غرق نکند. اگر دیوارههای آببند درست طراحی نشده باشند، میتوانند بیش از آنکه حل کنند مشکل بسازند، همانطور که در RMS Titanic رخ داد؛ و وقتی بحثش شد، در فیلم Titanic قطعا دو نفر میتوانستند روی آن تخته جا شوند!
ایده کلید قطع حل یا ریشهکن کردن مشکل نیست، بلکه خریدن زمان برای حل مسئله در ریشه آن است. دو نمونه از کلید قطع دیجیتال عبارتاند از:
- غیرفعال کردن دسترسی شبکه به ماشین یا زیرشبکه
- خاموش کردن برق، یا تعلیق کردن اگر مجازی است
محدود کردن خسارت هنگام ادامه داشتن حمله حیاتی است. این لزوما به معنی پایین آوردن کل سازمان به زیان شرکت نیست. شاید بتوانید با طراحی درست کلیدهای قطع حوزه را جدا کنید، اما اگر ممکن نیست، امنتر است برای مدتی خاموش شوید، بهویژه اگر گمان دارید داده حساس کاربر در معرض نفوذ قرار گرفته است.
۱۲.۸.۲ ارتباطات
ارتباط مهم است. در جریان نگه داشتن تیم اجرایی در طول یک وضعیت، حمایت و فضایی را به شما میدهد تا مشکل را حل کنید. مثل حواسپرتی حس خواهد شد، اما همانطور که پیشتر اشاره شد، «بهروزرسانیِ بدون خبر تازه» دورهای افراد را آگاه نگه میدارد و تیم شما را متمرکز بر مشکل نگه میدارد.
وقتی مشکل را جدا کردید، تمرکز به تعیین خسارت منتقل میشود تا بتوانید بفهمید چگونه آن را حل کنید و از تکرارش جلوگیری کنید. خسارت میتواند از سوءاستفاده از منابع، مثل انکار سرویس، تا حذف یا حذف داده، و تا رمزگذاری برای حمله باجافزاری امتداد داشته باشد. تعیین خسارت یک چیز است، اما همچنین باید مطمئن شوید مهاجمان دیگر در موقعیتی نیستند که پس از اینکه فکر کردید مسئله را حل کردهاید حمله را ادامه دهند یا دوباره شروع کنند.
بسته به تجربه تیم شما، هیچکس اگر خدمات شرکت امنیتی تخصصی را به کار بگیرید، نگاه عجیبی به شما نخواهد کرد. آنها تخصص لازم را دارند تا نهتنها به ریشهکن کردن مشکل کمک کنند، بلکه مطمئن شوند دوباره رخ نمیدهد.
شناسایی اینکه هکرها چگونه دسترسی گرفتند و بستن آن، به شما اطمینان میدهد که پس از بازیابی شدن، دوباره به خانه اول برنمیگردید. هیچ چیز بدتر از بازی «موشکوبی» نیست؛ فکر میکنید حلش کردهاید، اما بهمحض اینکه خاموش میکنید، دوباره ظاهر میشوند.
پاکسازی یک محیط تلاش، زمان و تخصص میخواهد، و هرقدر فکر کنید آن را تمیز کردهاید، همیشه شک کوچکی میماند که آیا همه چیز را گرفتهاید یا نه. اگر در این وضعیت قرار گرفتید، قطعا توصیه میکنم تخصص یک سرویس شخص ثالث را استخدام کنید. اگرچه معماریهای مدرن با همه اتصالهای درونی خود میتوانند ریسکهای امنیتی بیشتری ایجاد کنند، میتوانند بازیابی کردن سازمان را نیز آسانتر کنند، بهویژه اگر از کانتینرها در محیط مجازیسازیشده استفاده میکنید؛ فقط کانتینر را نابود کنید و تازه و تمیز دوباره بالا بیاورید، البته با این فرض که کتابخانه سرکش را در فرایند ساخت راه نداده باشید.
۱۲.۸.۳ مدیریت رخنه امنیتی
حوزه دیگری که ممکن است مجبور شوید مدیریت کنید، پیامدهای یک رخنه امنیتی یا سرقت داده است. این وضعیتی است که باید تعیین کنید چه چیزی دزدیده شده است. برخلاف زمانی که دارایی فیزیکی برداشته میشود و آشکار است چون دیگر آنجا نیست، دارایی دیجیتال میتواند شفاف کپی شود و هیچ اثری نگذارد. امیدوارم لاگگیری شما کافی باشد که اثری وجود داشته باشد؛ وگرنه اصلا از کجا متوجه سرقت میشدید؟ این کار اغلب جرمیابی دیجیتال نامیده میشود.
امنترین کاری که میتوانید بکنید این است که فرض کنید مهاجمان هر چیزی را که برایشان قابل دسترس بوده بردهاند. وقتی فهرست چیزها را تعیین کردید، باید موارد زیر را بفهمید:
- چه کسانی باید مطلع شوند؟
- چه گامهایی میتوانید برای خنثی کردن ارزش داده بردارید؟
- چه محافظهایی میتوانید بگذارید تا از سرقتهای بیشتر جلوگیری شود؟
- آیا پیامد حقوقی از این سرقت وجود دارد؟
بهترین توصیه من این است که تلاش نکنید این کار را بهتنهایی انجام دهید. تیم اجرایی خود را درگیر کنید، با مشاور حقوقی مشورت کنید و خدمات شرکتی تخصصی را بگیرید.
همه ما ایمیلهای «نگران نشوید، اما...» را از CEOها یا CTOهای شرکتهای بزرگ پس از هک داده دریافت کردهایم. این ایمیلها نتیجه بررسی آنهاست که نشان میدهد حساب یا داده شما احتمالا در معرض نفوذ قرار گرفته است. آنها بهعنوان نگهبانان خوب داده شما، هشدار میدهند تا نسبت به هر چیز مشکوکی آماده باشید.
گامهایی که همه دیدهایم شامل بازنشانی اجباری رمز عبور همه یا بازنشانی یکباره حساب است که کد تایید از طریق ایمیل یا SMS میخواهد. هرقدر کوچک باشد، تلاشی است برای خنثی کردن سودمندی داده. اما برای برخی سرقتهای داده، مثل نام، نشانی یا شماره تامین اجتماعی، کار بسیار کمی میتوان انجام داد و همین سرقت داده را عملی چنین جدی میکند. مشتریان شما که داده ارزشمند خود را به شما سپرده بودند تا مراقبت و نگهداری کنید، به بدترین شکل ناامید شدهاند.
بسته به نوع داده، ممکن است ناچار باشید درباره رخنه گزارش عمومی ثبت کنید. معمولا هر دادهای که شامل مالی یا سلامت باشد زیر این چتر قرار میگیرد، اما پیش از هر اقدامی از تیم حقوقی خود مشورت بگیرید.
رسیدن به ریشه هر نوع حمله یا رخنه میتواند زمان ببرد. آنچه ناگزیر رخ خواهد داد این است که کشف میکنید رخنه در حوزهای بوده که لاگگیری در آن کم یا غایب است. این قابل انتظار است و بهراحتی اصلاح میشود.
در بررسی خود دقیق باشید و آن را به شکلی ارائه کنید که برای کسانی که لزوما فنی نیستند بهراحتی قابل هضم باشد. چارچوب ساده چهارمرحلهای زیر را برای ساختار دادن به گزارش رخداد در نظر بگیرید: مسئله، شناسایی، اثر، راهکار یا IIIR:
- مسئله: تعریف کنید چه اتفاقی افتاد، شامل اینکه چگونه رخ داد
- شناسایی: نشان دهید مسئله چگونه به توجه شما رسید
- اثر: نتیجه مسئله را مرور کنید
- راهکار: گامهای حل و رسیدگی به رخداد را شرح دهید
نمونهای از بیانیه IIIR چنین است:
- مسئله: فرم وبی که برای بهروزرسانی جزئیات نشانی کاربران استفاده میشد به هر کسی با حساب اجازه میداد فقط با افزایش ID در فراخوانی API از طریق کنسول توسعهدهنده مرورگر، هر نشانی دیگری را ببیند.
- شناسایی: افزایش استفاده از فراخوانی APIها به تیم Ops هشدار داد بیشتر بررسی کند، و آنها فراخوانی APIهای مشکوک نشانی را از همان IP نشانی پیدا کردند.
- اثر: یک IP نشانی که تصور میشود یک کاربر بوده، پیش از اینکه تیم Ops دسترسیاش را قطع کند تقریبا ۱۰۰۰ نشانی را دیده است. کاربر قابل شناسایی نبود چون IP لاگها همراه ورودهای اخیر کاربر ذخیره نمیشوند.
- راهکار: نقطه پایانی مربوط به API بهروزرسانی و مستقر شده تا فقط نشانی کاربر ورود شده را برگرداند. همه APIهای دیگر در حال ممیزی و بهروزرسانی مشابهاند. IP لاگها بهعنوان بخشی از ردیابی نشست کاربر ذخیره میشوند. فهرستی از همه حسابهایی که نشانیهایشان دیده شده ساخته شده است.
این IIIRها بسته به رخداد میتوانند طولانی باشند. هدفشان فقط استفاده داخلی است و جزئیات کافی میدهند تا اگر اعلام عمومی مناسب دانسته شد، منبعی برای استخراج از آن باشد. این باید بیانیه واقعیت باشد، نه برنامهای برای تعیین کار بعدی؛ آن مسئولیت شما بهعنوان تیم اجرایی است.
۱۲.۹ مدیر ارشد امنیت اطلاعات (CISO)
در نهایت به اندازهای میرسید که نقش نگهداری امنیت و پایش و ردیابی انطباق آنقدر زیاد و مهم میشود که دیگر نمیتوان آن را میان تیم مهندسی توزیع کرد. افسر اختصاصی برای مدیریت این موضوع، و احتمالا رشد دادن یک تیم، بهترین مسیر پیش رو خواهد بود. معمولا این فرد را مدیر ارشد امنیت اطلاعات یا CISO مینامیم. برخی شرکتها این نقش را سادهتر مدیر ارشد امنیت مینامند.
تا این نقطه، به احتمال زیاد همه مسئولیت نگهداری و پایش امنیت بر عهده شما و تیم شما بوده است. برای اینکه CISO بتواند واقعا دستهای خود را باز کند و امنیت را در اختیار بگیرد، باید بیرون از گروه شما بنشیند.
Andy Wu، CEO شرکت CodeArcs، عبارت لاتین معروف «Quis custodiet ipsos custodes» را دوست دارد که تقریبا به «چه کسی نگهبانان را نگهبانی میکند؟» ترجمه میشود و با گونه «چه کسی مراقب مراقبان است؟» نیز شناخته میشود؛ وقتی موضوع نظارت امنیتی است. در این جهان، یعنی CISO نباید زیر رهبری شما بهعنوان CTO باشد. CISO نباید در موقعیتی باشد که نادیده گرفتن یا کاهش اثرش آسان باشد. باید کنار گروه شما کار کند و همزمان گروه شما را پاسخگو نگه دارد.
اگرچه این ممکن است مثل از دست دادن قدرت یا واگذار کردن زمین حس شود، دقیقا برعکس است. اعترافی به رشد و بلوغ پلتفرمی است که کسبوکار را نیرو میدهد. از کجا میدانید برای دفتر CISO آمادهاید؟
- شرکت شما باید به گواهیهای مختلف مرتبط با امنیت، از جمله انطباق، پایبند باشد.
- نوع دادهای که مدیریت میشود به رویهها و ردپاهای ممیزی مشخص نیاز دارد.
- محیط ممیزی امنیتی آنقدر بزرگ میشود که خودش یک شغل تماموقت است.
یک CISO خوب میتواند زمان و عمق لازم را برای امن نگه داشتن شرکت و دادههای شما اختصاص دهد و در شراکت با همه گروههای درگیر در مدیریت یا تولید داده کار کند.
جمعبندی
- وصلهکردن فراتر از بهروزرسانی کردن نرمافزار است؛ به تست و زمانبندی نیاز دارد.
- تستهای نفوذ، اگر پس از هر انتشار انجام نشوند، چیزی بیش از دارونما نیستند.
- کارکنان به دلیل حملات مهندسی اجتماعی ضعیفترین حلقه زنجیرند.
- رمزهای عبوری که بهراحتی تغییر نمیکنند دیگر کارکرد امنیتی ندارند.
- ایمنسازی محیط به هوشیاری و کار مداوم نیاز دارد.
- توسعه کد به آموزش و بازبینی نیاز دارد تا مطمئن شوید رخنهای وارد نمیشود.
- محیط ساختمان میتواند منبع حفرههای امنیتی باشد.
- ساختن دیوارههای آببند دیجیتال یا کلیدهای قطع امکان مهار یک رخنه را فراهم میکند.
- مدیریت رخنه امنیتی به خونسردی و ارتباطات داخلی خوب نیاز دارد.
- به نقطهای رشد خواهید کرد که منبع اختصاصی برای مدیریت امنیت لازم است.
چکلیست
چند مورد از موارد زیر را میتوانید ادعا کنید که پوشش دادهاید؟
- نرمافزارها و کتابخانههای شخص ثالث را طبق برنامه وصله منظم استفاده و بهروزرسانی میکنید.
- گزارش تست نفوذی دارید که به اندازه آخرین انتشار شما تازه است.
- فرایند آموزشی جاری برای یادآوری یا بهروزرسانی کارکنان درباره هکهای مهندسی اجتماعی اجرا میکنید.
- میتوانید همه رمزهای عبور را بدون نیاز به راهاندازی دوباره کردن اجزا سریع بچرخانید.
- لاگها و هشدارهای کافی دارید تا بدانید چه زمانی چیزی دچار رخنه شده است.
- چند کلید قطع برای محدود کردن حمله یا رخنه پیادهسازی کردهاید.
- فرایند آموزش و بازبینی برای توسعهدهندگان برقرار کردهاید تا حفرههای امنیتی وارد نکنند.
- محیط ساختی ساختهاید که به اندازه محیط تولید امن است.
خلاصه هوش مصنوعی
خلاصه فصل
امنیت وقتی درست انجام شود نامرئی به نظر میرسد؛ وقتی غلط انجام شود مزاحم یا فاجعهبار میشود. فصل ملاحظات امنیت سازمانی، توسعه امن (DevSecOps)، مدیریت بحران در زمان رخنه و زمان استخدام CISO اختصاصی را پوشش میدهد. حتی پلتفرمهای legacy هم میتوانند با گامهای عملی امنتر شوند.
- امنیت را از ابتدا در طراحی بگنجانید؛ افزودن در پایان پرهزینه و پراختلال است.
- فرض نکنید نبود حادثه به معنای امن بودن است — همانند فرض ضدآتش بودن خانه بدون آزمون.
- برنامه پاسخ به رخداد باید پیش از وقوع حادثه آماده و تمرین شده باشد.
این خلاصه با کمک هوش مصنوعی بر اساس محتوای فصل تهیه شده و جایگزین مطالعه کامل متن نیست.