ربط وحدات الأعمال المجمعة بـ AWS API Gateway
عندما تستحوذ Block على شركة أخرى، غالبًا ما نرغب في دمج خدمات الخلفية للاستفادة من تكنولوجيا بعضنا البعض. على سبيل المثال، يمكن للمرء أن يتخيل عملية استحواذ ترغب في الاستفادة من واجهات برمجة التطبيقات الداخلية، مثل مجموعة المدفوعات الداخلية لـ Block. قد يكون اقتراح التكامل الساذج هو وضع كلتا الشركتين على نفس الشبكة والبنية التحتية للمفاتيح العمومية. وبطبيعة الحال، وهذا هو أسهل من القيام به. علاوة على ذلك، هناك أسباب تتعلق بهندسة البنية التحتية والأمان والخصوصية لعزل أكثر صرامة.
في مقياس Block ، يعد تكامل الاستحواذ جهدًا مستمرًا. لتمكين أهداف العمل بسرعة Block ، نحتاج إلى أنماط تصميم قابلة لإعادة الاستخدام. في هذه المقالة، نستكشف كيف يتم حظر عمليات الاستحواذ في غضون أسابيع بدلاً من شهور.
لقد أنشأنا بنية تحتية داخل بيئة AWS الخاصة بـ Block والتي نطلق عليها اسم Farcars . تتيح Farcars عمليات الاستحواذ للاتصال بـ Block Service mesh من خلال الترجمة بسلاسة من دلالات الهوية الأصلية للاستحواذ إلى Block-original mTLS. من منظور الخدمات داخل الشبكة الداخلية لـ Block ، تعتبر اتصالات الاستحواذ مشاركين من الدرجة الأولى، ويتمتعون بدلالات authn / authz المتطابقة. تقوم خدمات الاستحواذ بإجراء مكالمات SIGv4 بأدوار IAM الحالية الخاصة بها في بوابة AWS API، والتي تتعامل مع ترجمة الهوية. النظام قيد الإنتاج لـ Afterpay و Tidal بينما نطرحه في وحدات أعمال أخرى.
مقدمة
داخليًا في Block ، غالبًا ما نشير إلى الشركة على أنها “نظام بيئي للشركات الناشئة”. على سبيل المثال، يعمل كل من Square و Cash App على شبكة الخدمة الخاصة بهما. بالنسبة لعمليات الاستحواذ مثل Afterpay أو TIDAL أو Weebly ، نحن مكلفون بدمج البنية التحتية الجديدة. نظرًا لأن المزيد من الشركات يمكن أن تنضم في المستقبل، فمن المهم أن تكون قادرًا على اكتساب عمليات استحواذ جديدة لشبكة خدماتنا بطريقة سريعة وآمنة لتمكين قيمة الأعمال.
تستخدم Block mTLS لتوفير هوية أعباء العمل وتأمين شبكتها الداخلية لأكثر من عقد من الزمان. لقد انتقلنا إلى الهويات المتوافقة مع SPIFFE في السنوات الأربع الماضية واستخدمنا SPIFFE كمعيار لمصادقة mTLS في جميع أنحاء الشركة. يوفر فريق Block’s Traffic سيارات جانبية Envoy، والتي تستخلص عناصر mTLS الداخلية من مطوري الخدمة. لإصدار بيانات اعتماد mTLS ، نستخدم مزيجًا من SPIRE والأنظمة الداخلية التي تعتمد على AWS Private CA التي كتبنا عنها سابقًا هنا.
يمكن للشركات المقتناة استخدام مجموعات وسحب تكنولوجية مختلفة. نتوقع احتمال أن يتراوح الوضع الأمني لعملية الاستحواذ من كلمات المرور المدارة يدويًا إلى حل السحابة الأصلي المنسق. نرغب في توسيع عروض شبكة الخدمة الخاصة بنا لتشمل وحدات الأعمال الجديدة هذه مع الحفاظ على معيار الأمان، دون الحاجة إلى عمليات الاستحواذ لتتماشى تمامًا مع البنية التحتية Block. نظرًا لأن Block يتكون من العديد من اللبنات الأساسية، يجب أن يتغلب مثل هذا الحل على عقبات قابلية التوسع. لترى كيف فعلنا ذلك، استمر في القراءة!
التحديات
كان الهدف من هذا المشروع بسيطًا: الانضمام إلى شركتين بطريقة تعمل خلفيتها كما لو كانت جزءًا من شركة واحدة. من الناحية المثالية، نريد إحداث أقل قدر ممكن من العمل في عملية الاستحواذ، لأن أعمال البنية التحتية يمكن أن تحل محل عمل المنتج. لتحقيق هذا الهدف، كان علينا التغلب على مجموعة من التحديات التي سنحددها في هذا القسم.
من منظور تنظيمي، تشغل Block فرقًا خاصة بهوية التشفير وحركة المرور، في حين أن معظم الشركات خاصة إذا كانت أصغر حجمًا لا تفعل ذلك. ومع ذلك، فإن Block ليس على دراية بمزايا وعموميات البنية التحتية داخل الشركات التي تم الاستحواذ عليها حديثًا. بينما يمكننا تقديم الخبرة المتخصصة، فقد لا نتمكن من دعم العمليات داخل البنية التحتية التي لسنا على دراية بها. يعد تنفيذ اكتساب الحل على نطاق واسع في بنية تحتية غير مألوفة عملية محفوفة بالمخاطر، ويجب أن تكون التغييرات هناك ضئيلة ويتم تنفيذها بواسطة مهندسين على دراية بالبنية التحتية للاستحواذ.
جانب آخر هنا هو قابلية التوسع، في حين أن النشر في مؤسسة AWS مختلفة معقد من الناحية اللوجستية، فإنه أيضًا أقل قابلية للتوسع من النشر في بيئة Block حيث يمكننا أن نكون أكثر مرونة في عملياتنا. ضع في اعتبارك على سبيل المثال العمل في خمسة بنى تحتية مختلفة مقابل تشغيل خمس تكوينات مختلفة لنفس البنية التحتية الوسيطة. إذا لم يكن هذا مقلقًا بما فيه الكفاية، فقم بعمل هذا الرقم 20. ونتيجة لذلك، قررنا أن البنية التحتية لدعم عمليات الاستحواذ يجب أن تعيش داخل الشركة الأم وأن يتم تقديمها كخدمة لعمليات الاستحواذ.
تعد قابلية التوسع أيضًا مصدر قلق من حيث الوقت الهندسي الذي يتم قضاؤه لتمكين عمليات الاستحواذ والخدمات الجديدة. البنية التحتية لدعم عمليات الاستحواذ الجديدة ليست مشكلة يجب حلها مرة واحدة فقط حيث يمكن أن يكون هناك المزيد من الشركات المنضمة. يجب أن يكون الحل عامًا بما يكفي ليكون قابلاً لإعادة الاستخدام مع شركات مختلفة تستخدم تقنيات مختلفة، وإلا فإننا سنخاطر بأداء نفس التمرين الهندسي في كل مرة نكتسب فيها شركة جديدة، وهو أمر غير مقبول. لقد كنا مهتمين جدًا بإنشاء نمط يوفر طريقًا ممهدًا لاستيعاب عمليات الاستحواذ المستقبلية.
نادرًا ما تعمل الشركات بلغة برمجة واحدة. نحن نستخدم لغات متعددة تعمل ضمن أطر داخلية مختلفة توفر الوصول إلى البنية التحتية الأساسية. كان هذا مصدر قلق آخر بشأن قابلية التوسع، لأننا لا نريد دعم بعض الأطر فقط وليس غيرها. أيضًا، يمكن إضافة أطر جديدة لاحقًا، مما قد يعني عمل التحديث المستقبلي وزيادة سطح التصحيح. من الناحية المثالية، ندعمهم جميعًا مرة واحدة ولن نحتاج إلى عمل في المستقبل. اللغة المشتركة لخدماتنا الخلفية هي mTLS عبر Envoy ، من خلال إيجاد Envoy ، يمكننا توفير دعم واسع النطاق لعمليات الاستحواذ للاتصال بدون تكلفة كبيرة لكل خدمة. وينطبق الشيء نفسه على عمليات الاستحواذ، تعتبر التغييرات الغازية على مجموعة البرامج بالكامل داخل شركة تم الاستحواذ عليها حديثًا لتمكين خدمة مكالمات الخدمة باهظة الثمن ولا تستحق النظر فيها. نريد أن تكون التغييرات على جانب الاستحواذ ضئيلة.
أدت مواجهة هذه التحديات إلى دفع بنية نظامنا. قررنا أنه من كلا الطرفين نريد دعم المكالمات في البيئة الأصلية، ونفعل ذلك من خلال تمكين الترجمة بين الخدمات على مستوى البنية التحتية. بشكل ملموس، يجب إنهاء المكالمات في شبكة خدمة Block في Envoy. إذا كانت خدمات Block قادرة على الوثوق بحركة الاستحواذ الصادرة عن Envoy ، فلا يلزم عمل جديد في الخدمات ويمكننا العمل بسرعة مطور عالية. علاوة على ذلك، يجب أن تعيش البنية التحتية للقيام بهذه الترجمة داخل Block حيث يمكن لفرق البنية التحتية لدينا تشغيلها بطريقة قابلة للتطوير لجميع عمليات الاستحواذ التي تريد الاتصال.
توفير البنية التحتية مقابل تقديم الشهادات الخام
تتمثل إحدى الأفكار لحل هذه التحديات في توزيع الشهادات والسماح لعملية الاستحواذ بمعالجة التفاصيل. يعمل نهج آلة بيع الشهادات هذا في إعدادات مقيدة ولكنه ليس نمطًا جيدًا يجب اتباعه لتكامل الشركات الجديدة.
يعد بدء TLS وإنهائه مصدرًا معروفًا للمشكلات التي نرى أن فرق البنية التحتية الكبيرة مجهزة بشكل أفضل للعمل على نطاق واسع مقارنة بمعظم الشركات الناشئة. هناك العديد من المشكلات التي يجب مواجهتها، سواء كانت تقوم بتحديث حزمة الثقة بانتظام، أو الاعتماد على الجزء “m” من “mTLS” الذي يتم تنفيذه بشكل صحيح، أو ترقية البروتوكولات، أو تحديث مكتبات التشفير. إذا كنا قادرين على التعامل مع هذا بطريقة نتحكم فيها في جميع عمليات الاستحواذ، فسيؤدي ذلك إلى تجنب مجموعة من المزالق.
بخلاف منع هذه المشكلات، يمكن أن تؤدي الإدارة المركزية وتجريد الهوية إلى تجربة مطور أفضل، من الناحية المثالية، نسعى جاهدين من أجل “الوضع السهل” حيث لا ينبغي للمطورين القلق بشأن PKI. على سبيل المثال، يتضمن Envoy تسجيلًا وتفاصيل هوية الملخص بعيدًا عن المطورين، ويبقينا مرنين إذا أردنا إضافة لغة برمجة أخرى مدعومة لاحقًا. أردنا تقديم تجربة مماثلة لعمليات الاستحواذ.
تصميم النظام
ساعدتنا مراعاة التحديات التي نواجهها في رؤية اتجاه عام للنظام. أردنا أن يكون النظام متوافقًا مع شبكة خدمة Envoy على الجانب Block ، بينما يتوافق مع ما تستخدمه عملية الاستحواذ على الجانب الآخر.
ما قمنا ببنائه نشير إليه باسم “وكيل بدون خادم”، يتكامل النهج مع شبكة خدمة mTLS على جانب واحد، مع توفير دخول مقيد بواسطة IAM على الجانب الآخر. نعتقد أن هذا النهج يوفر أفضل ما في العالمين دون المساومة على دقة هوية مستوى الخدمة أو إثقال كاهل أي من الجانبين بعمليات تكامل معقدة. يحتوي الخادم الوكيل الذي لا يحتوي على خادم على وكيل Envoy في حاوية عامل إرساء تعمل في AWS Fargate ، ويواجهها AWS API Gateway في وضع الوكيل. نشير إلى الحاوية باسم “Farcar” بدلاً من “sidecar”. إنها أبعد ما تكون عن عبء العمل الأصلي مما قد تكون عليه السيارة الجانبية، ولكن أيضًا لأنها تعمل في AWS Fargate.
لأغراض عزل عبء العمل، قدمنا حساب AWS جديدًا لكل عملية اكتساب لكل بيئة (مرحلة، إنتاج، …) داخل مؤسسة Block AWS. ضمن حسابات الوكيل هذه، نصدر بيانات اعتماد SPIFFE mTLS لكل Farcar التي تمثل خدمة اكتساب. يسمح ذلك لـ Block بالحفاظ على التحكم الكامل في الحساب وإدخال عناصر التحكم في الاتصال على بوابة API. كما أنه لا يمثل عبئًا على عملية الاستحواذ لنقل برامجهم إلى مؤسستنا كمتطلب. بينما تم تصميم هذا النهج مع وضع AWS في الاعتبار، يمكن لعمليات الاستحواذ التي تعمل في سحابات مختلفة أيضًا الاتصال بـ API Gateway ، نظرًا لاتصال الشبكة وبيانات اعتماد IAM، على سبيل المثال باستخدام IAM Anywhere. نعتقد أن هذا الحل عام بما يكفي لحل معظم حالات استخدام الاستحواذ. يتم تنفيذ هذا النظام كوحدة نمطية Terraform.
تعيد هندستنا استخدام أساليب الأمان المعمول بها: لدينا نموذج لأحمال العمل للاتصال من AWS إلى DC عبر mTLS الذي تم اختباره جيدًا. للاتصال من حساب الاستحواذ X إلى حساب وكيل الاستحواذ، نقوم بإنشاء عناصر تحكم IAM. يتم إنشاء حسابات الوكيل داخل مؤسسة Block AWS وتملكها فرق Block للبنية التحتية. ننشر مهمة Fargate لكل خدمة اكتساب ونقدم لهم NLB واحدًا لكل خدمة اكتساب. لا يمكن الوصول إلى حساب AWS الوكيل إلا من خلال VPC خاص للاستحواذ حتى لا يتم الكشف عن الوصول إلى مهام Fargate الخاصة بنا.
تصميم API
نحن نستخدم بوابة API واحدة لكل حساب وكيل لدخول حركة المرور من عملية استحواذ كاملة. على بوابة API، نقوم بتكوين مسار واحد لكل خدمة اكتساب. على سبيل المثال بالنسبة للخدمات X وY سنقوم بتكوين / X / * و / Y / *. يتم تقييد الوصول إلى هذه المسارات فقط بواسطة أدوار IAM المرتبطة بـ X وY على التوالي. لاستدعاء نقطة نهاية خدمة Block Z “foo” داخل شبكة خدمة Block من X، يجب على الخدمة X إنشاء طلب SIGv4 لبوابة API بالمسار “/ X / Z / foo”. نزيل البادئة “/ X / Z” ونمرر الطلب. الطلب الناتج يساوي ما سترسله الخدمات الداخلية Block. يمكن لخدمة الاستحواذ بشكل فعال التواصل مع خدمة Block بنفس الطريقة التي تتواصل بها الخدمات داخليًا مع Block.
دلالات الهوية والأمن
تحتفظ Block بنظام “إدارة وإدارة الهوية” (IGA) الذي يعمل كسجل لجميع أعباء العمل التي تعمل عبر الشركة. كشرط لاستخدام عمليات الاستحواذ على الوكيل بدون خادم، يجب أن تكون على متن هذا النظام. يحتوي نظام IGA الخاص بنا على سياق ما إذا كانت أعباء العمل جزءًا من عملية الاستحواذ ويمكنه إصدار شهادات بتنسيق مطابق وجعلها في متناول أعباء عمل Farcar. يتم إصدار هذه الشهادات مع SPIFFE URI SAN.
للحفاظ على دلالات الهوية، من الضروري الاحتفاظ بتخطيط 1: 1 في جميع أنحاء النظام. من المكونات الحاسمة العلاقة بين بوابة API ومهام Fargate التي تحتوي على Envoy ؛ أي شيء يمكنه التحدث إلى مهمة Fargate سيكون قادرًا على التصرف نيابة عن خدمات الاستحواذ هذه. ينبع هذا السلوك من حقيقة أن NLB لا يمكن أن يكون لها مجموعة أمان مرتبطة. – كان عزل NLB من أولويات تصميم الشبكة. إذا كان NLB على VPC مشترك على نطاق واسع، فإن أي شيء موجود على VPC يمكن أن يتحدث إلى NLB ويتولى دور أي خدمة اكتساب نحاول تأمينها. لمنع الوصول غير المرغوب فيه إلى Farcars ، تتصل عمليات الاستحواذ بواجهة تنفيذية (بوابة API) من VPC محدد لكل عملية اكتساب داخل مؤسسة Block.
بشكل عام، نحن نعيد استخدام الأساليب المجربة والمختبرة التي نعتمد عليها منذ سنوات. من خلال إصدار هوية mTLS في حسابات AWS داخل مؤسسة Block AWS الخاصة بنا وعزل وصول Fargate، نحافظ على دقة مستوى الخدمة. يتم إنشاء اتصالات mTLS من خلال Envoy. يتم توفير الأمان من خلال تقييد الوصول إلى حساب الوكيل على فرق البنية التحتية المحظورة والمراقبة عن كثب. ونتيجة لذلك، نقوم بتمكين أعباء العمل السحابية الأصلية بشفافية للعمل بطريقة متوافقة مباشرة مع شبكة خدمة mTLS الخاصة بنا.
ماذا عن الطريقة الأخرى؟
لتمكين مكالمات الخدمة إلى الخدمة من عمليات التزويد إلى Block ، نقبل المكالمات الموقعة في بوابة API حيث نقوم بترجمة المكالمة إلى mTLS في Envoy “Farcar”. بالعكس، لدعم المكالمات من مؤسسة Block إلى عمليات التزويد، نستخدم نفس النظام، ولكن يتعين علينا تعميمه. لدينا بالفعل قدرات للسماح لأعباء العمل بتولي أدوار IAMويمكن استدعاء API Gateway مباشرة. على الجانب المواجه لعملية الاستحواذ، نستخدم Farcars بطريقة مماثلة كما وصفنا سابقًا، ولكن بدلاً من استخدام mTLS تلقائيًا، نقوم بتغليف المنطق لهوية عبء العمل الأصلية للاكتساب المقابل، والتي قد تكون أو لا تكون mTLS. نحن بحاجة إلى التحلي بالمرونة لدعم بيئات الخدمة المختلفة. كمثال افتراضي، إذا كان الاستحواذ يستخدم مخطط توقيع مخصص، فيمكننا تطبيق ذلك في Farcar لاستخراجه بعيدًا عن الخدمات العاملة في Block. نقوم بتمكين الخدمات عبر جميع اللغات طالما يمكنهم الاتصال بـ API Gateway.
قائمة أمنيات AWS API Gateway
بينما تحل بوابة API العديد من المشكلات بالنسبة لنا، فإن أحد الجوانب السلبية الكبيرة هو عدم وجود دعم gRPC. في شكلها الحالي API Gateway تسمح فقط لـ HTTP / 1.1 مما يعني أن الطلبات والاستجابات تحتاج إلى ترجمتها إلى JSON، بالإضافة إلى حجم استجابة أقصى يبلغ 10 ميجابايت. بينما لدينا جسر JSON-to-proto للخدمات، فإن هذا يؤثر بلا داع على الأداء ويمنعنا من تدفق الردود. نحن ننتظر بفارغ الصبر تقديم HTTP / 2 لعملائنا في حالة قيام API Gateway بتمكين الدعم.
نحن سعداء ببوابة API بشكل عام. ومع ذلك، نأمل أن تؤدي التحسينات المستقبلية إلى تحسين الخدمة ودعم حالات الاستخدام على نطاق أوسع.
ملاحظة: نحن ندرك أنه يمكننا التبديل إلى خدمات AWS الأخرى للتغلب على قيود معينة على بوابة API. ومع ذلك، لم نعثر على أي عرض AWS حالي من شأنه أن يوفر مجموعة كاملة من الوظائف التي نحتاجها ونريد تجنب أي إعادة كتابة معمارية من شأنها أن تقدم حلاً جزئيًا.
خاتمة
يعد توصيل خدمات الواجهة الخلفية في سيناريو الاستحواذ عملية صعبة يمكن أن تستغرق أشهر الشركات. ناقشنا هنا حلاً تقنيًا لعمليات الاستحواذ على متن الطائرة للاتصال في غضون أسابيع والسماح لعمليات الاستحواذ بالانضمام إلى شبكة الخدمة بأمان واستدعاء أعباء العمل في Block كما لو كانت جزءًا من شبكة خدمة Block نفسها.
يستخدم حلنا بوابة API لترجمة بيانات اعتماد IAM إلى اتصال mTLS الذي نوفره بشفافية عبر وكيل Envoy الذي يعمل في AWS Fargate. لقد استخدمنا هذا النمط بنجاح لإدخال العديد من أنظمة إنتاج الاستحواذ بالفعل ولدينا عدد قليل من عمليات الدمج في خط الأنابيب.
شكر وتقدير
تطلب هذا المشروع تعاونًا واسعًا عبر فرق البنية التحتية وتعاونًا وثيقًا مع المهندسين في الشركات التي تم الاستحواذ عليها، وتحديداً Afterpay. شكرًا لفريق Traffic و Network Engineering و AWS Security. ملاحظة: إذا كان هذا النوع من العمل مثيرًا للاهتمام بالنسبة لك، فراجع صفحة الوظائف لدينا لمعرفة الأدوار المفتوحة في فريق InfoSec الخاص بنا.
المصدر: developer
قد يهمك:
