در رویداد AFCEA Alamo ACE در نوامبر ۲۰۲۳، هدفی بلندپروازانه به حضار اعلام شد. نیروی هوایی ایالات متحده، از طریق مدیر ارشد فناوری Jay Bonci، اعلام کرد که قصد دارد APIها را در سراسر نیروی هوایی ایالات متحده (USAF) مدرن و استانداردسازی کند و این کار از طریق پذیرش راهکارهای API-First انجام خواهد شد.
این تعهد اهمیت بالایی دارد زیرا میتواند الهامبخش توسعههای API-First در سایر ادارات دولتی نیز باشد. در ادامه، به بررسی این مفهوم میپردازیم، برنامههای USAF برای پذیرش آن و پیامدهای احتمالی این روند برای امنیت زیرساختهای USAF را بررسی میکنیم.
API-First چیست؟
API-First یک فلسفه طراحی نرمافزار است که توسعه رابطهای برنامهنویسی کاربردی (API) را در ابتدای پروژه در اولویت قرار میدهد. با قرار دادن API به عنوان معیار و راهنمای اصلی توسعه، APIها به عنوان مؤلفههای اصلی تلقی میشوند و نه یک محصول جانبی فنی.
در رویکرد API-First، API قبل از محصول یا سرویس واقعی طراحی میشود. این به این معناست که API یک فکر بعدی یا الحاقی به محصول موجود نیست، بلکه عنصر اصلی است که همه چیز حول آن ساخته میشود. در چنین رویکردی، نحوه تعامل کاربران با رابط، کیفیت مستندسازی و کارایی عملی آن، همه به عنوان شاخص سلامت API در نظر گرفته میشوند، که منجر به طراحی بهتر و تجربه توسعهدهنده بهبود یافته میشود.
استراتژی API-First معمولاً نیاز به همکاری بین کاربران بالقوه API و تیمهای توسعه داخلی دارد. این همکاری به معنای وارد شدن بازخورد در مراحل اولیه فرآیند است که باعث تطابق API با نیازهای کاربران و بهبود نتایج میشود. علاوه بر بهبود تجربه کاربری، این رویکرد میتواند به طرز چشمگیری زمان ورود محصول به بازار را کاهش دهد. از آنجا که API ابتدا توسعه مییابد، تیمهای فرانتاند و بکاند میتوانند بهصورت موازی کار کنند و توسعه سریعتر و محصولی با تطابق بهتر با نیاز واقعی فراهم شود.
رویکرد API-First مزایای غیرمستقیمی مانند قابلیت استفاده مجدد، قابل حمل بودن و ثبات بهتر در بخشهای مختلف اپلیکیشن ارائه میدهد. داشتن API طراحیشده از ابتدا همچنین مزایای بلندمدت دارد — سازگاری با فناوریها و پلتفرمهای جدید در آینده آسانتر خواهد بود و همواره تطابق با نیاز کاربران حفظ میشود. API-First میتواند به عنوان یک قرارداد پایدار بین بخشهای مختلف یک سیستم عمل کند، حتی زمانی که جزئیات اجرایی تغییر میکنند.
نیروی هوایی ایالات متحده به سمت API-First
اکنون که مدل API-First را به خوبی فهمیدیم، به یک مثال واقعی میپردازیم: نیروی هوایی ایالات متحده.
هر سازمان نظامی به یک چیز بستگی دارد: لجستیک. لجستیک ستون فقرات هر بخش مهم در نیروهای مسلح از دیرباز بوده است و این مفهوم اساسی پایه بسیاری از تلاشهای USAF برای بهبود APIهای خود است.
USAF برای اتصال هر حسگر و سیستم به منظور همگامسازی عملیات نیروهای مشترک در سراسر جهان تلاش کرده است. این هدف بسیار بزرگی است که با مشکلات پیچیدهای همراه است. علاوه بر اینکه هر حسگر و سیستم ممکن است دارای پلتفرم داخلی متفاوتی باشد، واقعیت این است که این سیستمها در جهانی با انواع روشهای ارتباطی، کیفیت شبکههای متصل و دسترسی عمومی منابع پراکنده هستند.
برای دستیابی به این هدف، USAF بر استانداردسازی APIهای خود از طریق طراحی API-First تمرکز کرده است. Jay Bonci، مدیر ارشد فناوری وزارت نیروی هوایی، این هدف را در رویداد AFCEA Alamo ACE در نوامبر ۲۰۲۳ بیان کرد:
«APIها امکان به اشتراکگذاری دادههای لحظهای و معتبر برای فرماندهی و کنترل همهجانبه نیروهای ائتلاف (CJADC2) را فراهم میکنند که موفقیت مأموریت را در سطح جهانی تضمین میکند.»
USAF قصد دارد هدف خود را با پذیرش طراحی API-First تحقق بخشد. بزرگترین ارزش این رویکرد، ماهیت بسیار تعاملی آن است. همانطور که Bonci اشاره کرد:
«ما قادر خواهیم بود بازخورد عمومی دریافت کنیم و این بازخورد برای همه در این جامعه [صنعت و خدمت] و همچنین جامعه مشترک [joint] است. ما میخواهیم اطمینان حاصل کنیم که با DoD و متحدان و شرکای خود همراستا هستیم.»
USAF تلاش خود را با استانداردسازی فرمتها، سیستمها و خدمات API آغاز کرده است، با تمرکز ویژه بر روی رویههای یکپارچه و تأیید صلاحیت. با متمرکز کردن فرآیند API که پایه سیستمهای لجستیکی USAF است، Bonci راهحلی برای مشکل سیستمهای داده متفاوت و مقیاسپذیری میبیند، بهویژه در رابطه با تازه بودن انبار داده و توانایی به اشتراکگذاری داده بین سازمانها و واحدها.
«ما سرمایهگذاری زیادی در پلتفرمهای داده داشتهایم، و آنها خدمات بسیار خوبی به تحلیلگران و جامعه علمی ما ارائه میدهند. اما آن دادهها قدیمی هستند. ما دادهها را وارد میکنیم و ممکن است شش ساعت، دوازده ساعت یا یک ماه قدیمی باشند. وقتی دادهها با قدیمی بودن متفاوت مقایسه میشوند، نتایج کمتر معتبر خواهند بود. اما این مدل هنوز عالی است. هنوز هم برای تحلیلهایی که نیاز به زمان واقعی ندارند عالی است. […] هر سازمان فناوری بزرگ به حل این چالش پرداخته و این خدمات را توسعه داده است. Microsoft، Amazon، Google، Teslaها این کار را کردهاند. این برای ما یک حوزه جدید است. ما باید تلاش کنیم تا سیستمهایمان با هم ارتباط برقرار کنند تا به JADC2 برسیم.»
USAF در حال حاضر دارای طیف وسیعی از APIها در پارادایمهای مختلف، از جمله REST و WebSocket است. مشکل اصلی آنها در حال حاضر، اتصال ضعیف و غیر استاندارد بین این سیستمها است، که بر توانایی اشتراک داده در مقیاس بزرگ و اطمینان از مقیاسپذیری فرآیندهای آنها در حوزههای جدید تأثیر میگذارد. از آنجا که API ابتدا توسعه نیافته است، تجربه معمولاً ضعیف است، حتی اگر هر API جداگانه وظایف فنی خود را به درستی انجام دهد.
قابل توجه است که Bonci این موضوع را به همان اندازه مشکل فنی میداند که مشکل اجتماعی:
«ما جزئیات فنی زیادی داریم که باید حل شوند. اما ما اصول این نوع مسائل را در معماری مرجع خود ترسیم خواهیم کرد تا بتوانیم بازخورد جامعه را دریافت کنیم، هم از نظر روابط تجاری برای نحوه کنترل دادهها توسط مالکان سیستمها و هم از نظر راهکارهای فنی برای توسعهدهندگان. در چند ماه آینده، موضوعات بیشتری در این حوزه منتشر خواهیم کرد. این برای زیرساخت داده ما، کارخانههای نرمافزار و جامعه بزرگ نرمافزار DAF، از جمله شرکای فروشنده حیاتی است. و برای داستان ما درباره JADC2 نیز کلیدی خواهد بود.»
این موضوع در پذیرش API-First برای سازمانهایی که با این رویکرد آشنا نیستند، صادق است. API-First بسیاری از پارادایمهای توسعه گذشته را کنار میگذارد و بنابراین میتواند هم تغییر ذهنی و فرهنگی برای توسعهدهندگان و هم تغییر پروژهها را در پی داشته باشد.
محیطهای Zero-Trust و تنظیمشده
محیطهای با تنظیمات شدید، مانند USAF، ملاحظات مهمی در مورد مفهوم Zero-Trust دارند. معماری Zero-Trust یک مفهوم امنیتی است که بر این باور استوار است که سازمانها نباید به طور خودکار هیچ چیز داخل یا خارج از محیط خود را اعتماد کنند و باید هر چیزی که سعی در اتصال به سیستمهایشان دارد را قبل از اعطای دسترسی بررسی کنند.
مدلهای امنیتی سنتی فرض میکردند که همه چیز داخل شبکه سازمان قابل اعتماد است اگر از یک سیستم شناخته شده و معتبر باشد. واقعیت این است که برخی از مخربترین حملات میتوانند از سیستمهای داخلی شبکه یا خدمات بیایند، و بنابراین همه چیز باید محتاطانه بررسی شود. Zero-Trust بر این اصل است که اعتماد هرگز نباید فرض شود، بدون توجه به اینکه درخواست از کجا میآید یا به چه منابعی دسترسی دارد.
Zero-Trust نیازمند تأیید هویت دقیق برای هر سیستم، فرد و دستگاهی است که سعی در دسترسی دارد، حتی اگر در داخل یا خارج از محدوده شبکه باشد. این سیستمها معمولاً از احراز هویت چندعاملی استفاده میکنند، که نیازمند بیش از یک شواهد برای تأیید کاربر است، مانند چیزی که کاربر میداند (رمز عبور)، چیزی که دارد (گوشی هوشمند) یا چیزی که هست (بیومتریک). Zero-Trust همچنین نیازمند محدود کردن دسترسی کاربران از طریق اصل حداقل دسترسی و ایمنسازی دادهها و فرآیندهاست که دسترسی تنها وقتی اعطا شود که برای عملکرد خاصی لازم باشد.
این رویکرد نیازمند بررسی و پایش مستمر است. وضعیت امنیتی تنها یک تأیید یکباره نیست — بلکه نیازمند بررسیهای مداوم برای اطمینان از کامل بودن و کارآمد بودن است.
از آنجا که USAF در میان سیستمهایی فعالیت میکند که برخی از امنترین عملکردهای ایالات متحده را مدیریت میکنند، سیستمهای زیرساختی باید در چارچوب معماری Zero-Trust عمل کنند. در حالی که سایر سیستمها ممکن است گاهگاهی توسط هکرها یا مجرمان تهدید شوند، USAF در هر لحظه عملاً در میانه جنگ سایبری است. بنابراین، چنین سازمانهایی باید API خود را به عنوان هدف اصلی برای عملیات داخلی و خارجی در نظر بگیرند.
نتیجهگیری
حرکت USAF به سمت پذیرش API-First تصمیمی منطقی است. نیروی هوایی از داشتن زیرساخت فرماندهی متمرکز بهره میبرد که امکان هدایت توسعه جهانی را فراهم میکند، و در این مورد، پذیرش API-First به عنوان پارادایم توسعه متمرکز میتواند تجربهای امنتر، قابل توسعهتر و کاربرپسندتر فراهم کند.
