شبکه و امنیت برنامه بهتر با CAKES

چگونه پشته CAKES، با محوریت Kubernetes، چالش‌های API، شبکه، امنیت و انطباق را برطرف می‌کند و در عین حال تحویل را سرعت می‌بخشد و هزینه‌ها را کاهش می‌دهد.

• چرا کیک؟
• رویکردی بهتر برای شبکه‌سازی برنامه
• نیازهای امنیتی و شبکه مدرن
• استراتژی برای اتخاذ کیک

برنامه‌های نرم‌افزاری مدرن زیربنای وب بزرگ و رو به رشدی از APIها، سرویس‌های میکرو و سرویس‌های ابری هستند که باید بسیار در دسترس باشند، خطا قابل تحمل و ایمن فناوری شبکه زیربنایی باید از همه این الزامات پشتیبانی کند، البته از رشد انفجاری نیز پشتیبانی کند.

متأسفانه، نسل قبلی فناوری‌ها برای حل مناسب این چالش بسیار گران، شکننده و ضعیف هستند. همراه با شیوه‌های غیربهینه سازمانی، الزامات انطباق با مقررات، و نیاز به ارائه سریع‌تر نرم‌افزار، نسل جدیدی از فناوری برای رسیدگی به این چالش‌های API، شبکه و امنیت لازم است.

CAKES یک پشته شبکه برنامه منبع باز است که برای ادغام و حل بهتر این چالش ها ساخته شده است. این پشته قرار است با شیوه‌های مدرنی مانند GitOps، پیکربندی اعلامی و مهندسی پلتفرم همراه شود. CAKES بر اساس فناوری های منبع باز زیر ساخته شده است:

• C – CNI (رابط شبکه کانتینری) / Cilium، Calico
• A – مش محیطی / ایستیو
• K – Kubernetes
• E – Envoy / دروازه API
• S – SPIFFE / SPIRE

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

چرا کیک؟

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

قانون کانوی دوباره به اجرا درآمد

یک چالش بزرگ در شرکت‌های امروزی، همگامی با نیازهای شبکه‌ای معماری‌های مدرن است و در عین حال سرمایه‌گذاری‌های فناوری موجود را نیز به خوبی اجرا می‌کنند. سازمان‌های بزرگ دارای چندین تیم فناوری اطلاعات هستند که این نیازها را بر عهده دارند، اما گاهی اوقات، اشتراک‌گذاری اطلاعات و ارتباط بین این تیم‌ها کمتر از حد ایده‌آل است. کسانی که مسئول اتصال، امنیت و انطباق هستند معمولاً در عملیات شبکه، امنیت اطلاعات، زیرساخت پلت فرم/ابر و/یا مدیریت API زندگی می کنند. این تیم ها اغلب در سیلوها تصمیم می گیرند که باعث تکرار و اصطکاک یکپارچه با سایر بخش های سازمان می شود. اغلب اوقات، “ادغام” بین این تیم ها از طریق سیستم های فروش بلیط انجام می شود.

به عنوان مثال، یک تیم عملیات شبکه عموماً بر فناوری اتصال، DNS، زیرشبکه‌ها، تقسیم‌بندی میکرو، تعادل بار، دستگاه‌های فایروال، نظارت/هشدار و موارد دیگر نظارت می‌کند. یک تیم امنیت اطلاعات معمولاً در سیاست‌های انطباق و ممیزی، مدیریت فایروال‌های برنامه‌های وب (WAF)، تست نفوذ، اسکن کانتینر، بازرسی بسته‌های عمیق و غیره مشارکت دارد. یک تیم مدیریت API از نصب، ایمن سازی، فهرست نویسی و انتشار API ها مراقبت می کند.

اگر هر یک از این تیم ها به طور مستقل فناوری سیلو خود را انتخاب کنند، یکپارچه سازی و اتوماسیون کند، شکننده و گران خواهد بود. تغییرات در خط مشی، مسیریابی و امنیت، شکاف هایی را در انطباق آشکار می کند. ممکن است تیم ها در مورد اینکه از کدام فناوری استفاده کنند سردرگم شوند، زیرا به ناچار همپوشانی وجود خواهد داشت. زمان‌بندی تغییرات در پشتیبانی از بهره‌وری توسعه‌دهنده برنامه طولانی‌تر و طولانی‌تر می‌شود. به طور خلاصه، قانون کانوی، که بیان می کند که یک سیستم سازمانی اغلب مانند ساختار ارتباطی آن سازمان به پایان می رسد، سر زشت خود را بالا می برد.

شکل ۱. سیلوهای فناوری منجر به انتخاب های تکه تکه فناوری، ادغام های گران قیمت و شکننده و همپوشانی می شوند

عملکردهای سازمانی کمتر از حد مطلوب

قانون کانوی تنها موضوع اینجا نیست. شیوه های سازمانی در این زمینه می تواند کمتر از حد مطلوب باشد. پیاده‌سازی‌ها بر اساس مورد به مورد، منجر به بسیاری از «جزایر شبکه‌ای» منزوی در یک سازمان می‌شوند، زیرا کارها «همیشه انجام می‌شدند» اینگونه است.

به عنوان مثال، خط جدیدی از کسب و کار ایجاد می شود که خدمات را به بخش های دیگر کسب و کار ارائه می دهد و خدمات را از بخش های دیگر مصرف می کند. روش کار ایجاد یک VPC جدید (ابر خصوصی مجازی)، نصب متعادل کننده های بار جدید F5، فایروال های جدید Palo Alto، ایجاد یک تیم جدید برای پیکربندی و مدیریت آن و غیره است. جزایر شبکه که ادغام و مدیریت آنها دشوار است.

با گذشت زمان، هر تیم به طور مستقل چالش های موجود در محیط خود را حل می کند. کم کم این جزایر شبکه شروع به دور شدن از یکدیگر می کنند. به عنوان مثال، ما در Solo.io با موسسات مالی بزرگی کار کرده‌ایم که یافتن ده‌ها و نه صدها جزیره از این شبکه‌های متحرک معمول است. الزامات امنیت و انطباق سازمانی برای یکنواخت و قابل بازرسی در محیطی مانند آن بسیار دشوار است.

شکل ۲. شیوه های موجود منجر به تکرار و پیچیدگی گران قیمت می شود.

فرض‌ها و کنترل‌های شبکه قدیمی

در نهایت، مفروضاتی که درباره امنیت شبکه محیطی و کنترل‌هایی که برای اجرای خط‌مشی امنیتی و خط‌مشی شبکه استفاده می‌کنیم، دیگر معتبر نیستند. ما به طور سنتی اعتماد زیادی به محیط شبکه و «جایی» که خدمات در جزایر شبکه یا بخش‌های شبکه مستقر می‌شوند، اختصاص داده‌ایم. وقتی سوراخ‌های بیشتری در دیوار آتش ایجاد می‌کنیم، از سرویس‌های ابری بیشتری استفاده می‌کنیم، و APIها و ریزسرویس‌های بیشتری را در محل‌ها و در ابرهای عمومی (یا در چندین ابر عمومی طبق مقررات درخواست می‌کنیم) «محیط» بدتر می‌شود. هنگامی که یک عامل مخرب از محیط عبور می کند، به سیستم های دیگر دسترسی جانبی دارد و می تواند به داده های حساس دسترسی داشته باشد. سیاست‌های امنیتی و انطباق معمولاً مبتنی بر آدرس‌های IP و بخش‌های شبکه هستند که زودگذر هستند و می‌توان آنها را مجدداً تخصیص داد. با تغییرات سریع در زیرساخت، “پوسیدگی بیت سیاست” به سرعت و به طور غیرقابل پیش بینی اتفاق می افتد.

پوسیدگی بیت خط‌مشی زمانی اتفاق می‌افتد که می‌خواهیم خط‌مشی را اجرا کنیم، اما به دلیل تغییر در زیرساخت‌های پیچیده و قوانین شبکه مبتنی بر IP، این خط‌مشی منحرف یا نامعتبر می‌شود. بیایید یک مثال ساده از سرویس A در حال اجرا در VM 1 با آدرس IP 10.0.1.1 و سرویس B در حال اجرا در VM 2 با آدرس IP 10.0.1.2 را در نظر بگیریم. می‌توانیم خط‌مشی بنویسیم که می‌گوید «سرویس A باید بتواند با سرویس B صحبت کند» و آن را به عنوان قوانین فایروال اجرا کنیم که به ۱۰.۰.۱.۱ اجازه می‌دهد با ۱۰.۰.۱.۲ صحبت کند.

شکل ۳. سرویس A فراخوانی سرویس B در دو ماشین مجازی مختلف با خط مشی مبتنی بر IP.

دو اتفاق ساده می تواند در اینجا بیفتد تا خط مشی ما را خراب کند. اول، یک سرویس جدید C می تواند در VM 2 مستقر شود. نتیجه، که ممکن است در نظر گرفته نشده باشد، این است که اکنون سرویس A می تواند سرویس C را فراخوانی کند. دوم، VM 2 می تواند ناسالم شود و با یک آدرس IP جدید بازیافت شود. آدرس IP قدیمی را می توان دوباره به یک VM 3 با سرویس D اختصاص داد. اکنون سرویس A می تواند با سرویس D تماس بگیرد اما به طور بالقوه سرویس B را ندارد.

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

مثال قبلی برای یک مورد استفاده بسیار ساده است، اما اگر این مورد را به صدها ماشین مجازی با صدها یا نه هزاران قانون دیوار آتش پیچیده گسترش دهید، می‌توانید ببینید که چگونه تغییرات در محیط‌هایی مانند این می‌تواند منحرف شود. هنگامی که پوسیدگی بیت سیاست اتفاق می افتد، درک سیاست فعلی بسیار دشوار است مگر اینکه چیزی شکسته شود. اما فقط به این دلیل که ترافیک در حال حاضر قطع نمی‌شود، به این معنی نیست که وضعیت سیاست آسیب‌پذیر نشده است.

قانون کانوی، زیرساخت‌های پیچیده و فرضیات شبکه منسوخ شده، باتلاقی پرهزینه ایجاد می‌کند که سرعت تحویل را کاهش می‌دهد. ایجاد تغییرات در این محیط‌ها منجر به اثرات غیرقابل پیش‌بینی امنیتی و سیاست‌گذاری می‌شود، حسابرسی را دشوار می‌کند و شیوه‌های ابری مدرن و اتوماسیون را تضعیف می‌کند. به این دلایل، ما به یک رویکرد مدرن و جامع برای شبکه‌سازی برنامه‌ها نیاز داریم.

رویکردی بهتر برای شبکه سازی برنامه

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

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

شکل ۵. یک تیم مهندسی پلتفرم پیچیدگی زیرساخت را انتزاعی می کند و یک تجربه توسعه دهنده را از طریق یک پورتال توسعه دهنده داخلی به تیم های توسعه دهنده برنامه ارائه می دهد.

برای موفقیت یک تیم مهندسی پلتفرم، باید ابزارهایی را در اختیار آنها قرار دهیم که برای زندگی در این دنیای مدرن و بومی ابری مجهزتر باشند. وقتی به شبکه سازی، امنیت و انطباق فکر می کنیم، باید به نقش ها، مسئولیت ها و خط مشی هایی فکر کنیم که می توانند مستقیماً به سازمان نگاشت شوند.

باید از تکیه بر «محل استقرار» چیزها، آدرس‌های IP استفاده شده و قوانین بخش‌بندی خرد یا فایروال خودداری کنیم. ما باید بتوانیم به سرعت به وضعیت “در نظر گرفته شده” خود نگاه کنیم و به راحتی آن را با استقرار یا سیاست موجود مقایسه کنیم. این امر ممیزی را ساده تر می کند و اطمینان از انطباق را آسان تر می کند. چگونه به آن دست یابیم؟ ما در ابزارهای خود به سه مفهوم اساسی ساده اما قدرتمند نیاز داریم:

• پیکربندی اعلامی
• هویت حجم کاری
• نقاط ادغام استاندارد

پیکربندی اعلامی

هدف و وضعیت فعلی اغلب به دلیل پیچیدگی‌های زیرساخت سازمان مخدوش می‌شوند. تلاش برای عبور از هزاران خط از قوانین فایروال مبتنی بر آدرس‌های IP و تقسیم‌بندی شبکه و درک مقصود تقریباً غیرممکن است. قالب‌های پیکربندی اعلامی به حل این مشکل کمک می‌کنند.

به جای هزاران مرحله ضروری برای دستیابی به وضعیت مطلوب، پیکربندی اعلامی به ما اجازه می دهد تا به وضوح بیان کنیم که هدف یا وضعیت نهایی سیستم باید چه باشد. ما می‌توانیم به وضعیت زنده یک سیستم نگاه کنیم و آن را با حالت مورد نظر آن با پیکربندی اعلامی بسیار راحت‌تر از تلاش برای مهندسی معکوس از طریق مراحل و قوانین پیچیده مقایسه کنیم. اگر زیرساخت تغییر کند، می‌توانیم خط‌مشی اعلامی را برای این هدف جدید که امکان چابکی را فراهم می‌کند، «دوباره کامپایل» کنیم.

شکل ۶. چه چیزی را بیان کنید، نه چگونه.

نوشتن خط مشی شبکه به عنوان پیکربندی اعلامی کافی نیست. سازمان‌های بزرگ را دیده‌ایم که مدل‌های پیکربندی اعلامی خوبی می‌سازند، اما پیچیدگی زیرساخت‌های آنها همچنان به قوانین پیچیده و اتوماسیون شکننده منجر می‌شود. پیکربندی اعلامی باید بر حسب هویت بار کاری قوی نوشته شود که به خدمات نگاشت شده با ساختار سازمان گره خورده است. این هویت حجم کاری مستقل از زیرساخت، آدرس‌های IP، یا ریزبخش‌بندی است. هویت بار کاری به کاهش پوسیدگی بیت خط مشی کمک می کند، تغییر پیکربندی را کاهش می دهد و استدلال در مورد وضعیت مورد نظر سیستم و وضعیت واقعی را آسان تر می کند.

هویت حجم کاری

روش‌های قبلی ایجاد خط‌مشی بر اساس «محلی» که بارهای کاری مستقر می‌شوند، بسیار مستعد ابتلا به «پوسیدگی بیت سیاست» هستند. ساختارهایی مانند آدرس‌های IP و بخش‌های شبکه بادوام نیستند، یعنی زودگذر هستند و می‌توان آن‌ها را تغییر داد، دوباره تخصیص داد یا حتی مرتبط نیستند. تغییرات در این ساختارها می تواند خط مشی مورد نظر را باطل کند. ما باید حجم کاری را بر اساس آنچه هستند، نحوه ترسیم آنها در ساختار سازمانی شناسایی کنیم و این کار را مستقل از محل استقرار آنها انجام دهیم. این جداسازی به خط‌مشی مورد نظر اجازه می‌دهد هنگام تغییر زیرساخت، استقرار در محیط‌های ترکیبی، یا تجربه خطا/شکست، در برابر رانش مقاومت کند.

شکل ۷. هویت بار کاری قوی باید در هنگام راه اندازی به بارهای کاری اختصاص داده شود. خط‌مشی‌ها باید بر اساس هویت بادوام نوشته شوند، صرفنظر از اینکه بار کاری در کجا مستقر شده‌اند.

با هویت حجم کاری بادوام‌تر، می‌توانیم خط‌مشی‌های احراز هویت و مجوز را با پیکربندی اعلامی بنویسیم که ممیزی آسان‌تر است و به وضوح با الزامات انطباق نگاشت می‌شود. اجرای یک الزام انطباق در سطح بالا مانند “محیط های آزمایش و توسعه دهنده نمی توانند با محیط های تولید یا داده ها تعامل داشته باشند” آسان تر می شود. با شناسایی حجم کار، می دانیم که کدام بار کاری به کدام محیط تعلق دارد زیرا در هویت حجم کاری آنها کدگذاری شده است.

اکثر سازمان‌ها در حال حاضر سرمایه‌گذاری‌های موجود در سیستم‌های مدیریت هویت و دسترسی دارند، بنابراین آخرین قطعه از پازل در اینجا نیاز به نقاط ادغام استاندارد است.

نقاط ادغام استاندارد

یک دردسر بزرگ در پیاده‌سازی‌های امنیتی و شبکه‌های موجود، ادغام‌های گران قیمت بین سیستم‌هایی است که قرار نبود با هم خوب کار کنند یا نقاط ادغام اختصاصی را نشان می‌دهند. برخی از این ادغام ها به شدت مبتنی بر UI هستند که خودکار کردن آنها دشوار است. هر سیستمی که بر اساس پیکربندی اعلامی و هویت بار کاری قوی ساخته شده باشد، باید با لایه‌های دیگر در پشته یا فناوری پشتیبانی ادغام شود.

• کوبرنتس
• ظروف
• خدمات میکرو
• ابر بومی
• توسعه نرم افزار< /a>
• شبکه‌سازی
• امنیت برنامه< /a>