سياسة تفويض Apache APISIX: حماية واجهات برمجة التطبيقات (APIs) الخاصة بك
April 21, 2023
مقدمة
في الوقت الحاضر، أصبحت واجهات برمجة التطبيقات (APIs) الجسر الذي يربط بين الأنظمة والتطبيقات المختلفة من حيث البيانات والوظائف. بينما نستمتع بسهولة استخدام واجهات برمجة التطبيقات، أصبحت ضمان أمان البيانات وتجنب تسرب البيانات وغيرها من المشكلات الأمنية من أهم اهتمامات المستخدمين. في هذه المرحلة، يلعب التحكم في الوصول دورًا حاسمًا. من خلال وضع سياسات تحكم في الوصول مناسبة لواجهات برمجة التطبيقات، يمكنك ليس فقط حماية واجهات برمجة التطبيقات من الهجمات السيبرانية الضخمة وضمان أمان البيانات، ولكن أيضًا مساعدة الشركات على الوفاء بمتطلبات الامتثال وتعزيز ثقة العملاء.
Apache APISIX هو بوابة واجهة برمجة تطبيقات سحابية ديناميكية وفعالة في الوقت الفعلي وعالية الأداء، حيث يوفر مجموعة غنية من ميزات إدارة حركة المرور مثل موازنة الحمل، والخادم العلوي الديناميكي، والإصدار التدريجي، وكسر الدائرة الخدمية، والمصادقة، والمراقبة. في هذه المقالة، سنقدم سياسات التحكم في الوصول الخاصة بـ Apache APISIX ونناقش الاستراتيجيات الشائعة التي يمكن استخدامها لحماية أمان واجهات برمجة التطبيقات الخاصة بك وضمان التشغيل المستقر لنظامك.
ما هي سياسة التحكم في الوصول؟
سياسات التحكم في الوصول هي آليات أمنية مصممة لحماية البيانات أو الموارد الحساسة في أنظمة الكمبيوتر أو الشبكات أو التطبيقات، مما يضمن أن المستخدمين أو التطبيقات المصرح لهم فقط يمكنهم الوصول إليها. هذا يساعد على تقليل مخاطر تسرب البيانات والثغرات الأمنية. في بوابة واجهة برمجة التطبيقات، تعد سياسات التحكم في الوصول مكونًا أساسيًا. حيث تعتبر بوابة واجهة برمجة التطبيقات نقطة الدخول لجميع حركة المرور، وهي مسؤولة عن استقبال وإعادة توجيه جميع طلبات واجهات برمجة التطبيقات. لذلك، تحدد سياسات التحكم في الوصول الخاصة ببوابة واجهة برمجة التطبيقات بشكل مباشر أمان واستقرار الخدمات العلوية.
سياسات التحكم في الوصول الشائعة في Apache APISIX
يوفر Apache APISIX مجموعة غنية من سياسات التحكم في الوصول، حيث يدعم بروتوكول المصادقة OAuth 2.0 ويتكامل مع العديد من خدمات المصادقة الخارجية مثل Keycloak وOry Hydra وOkta وAuth0 وغيرها. بالإضافة إلى دعم خدمات المصادقة الخارجية، يوفر APISIX أيضًا طرق مصادقة داخلية قوية. بالاقتران مع كائن Consumer الخاص بـ APISIX، يمكنك مزج وتركيب المصادقة، والتفويض، والحد من المعدل، وقوائم الحظر والسماح بناءً على IP لحماية واجهات برمجة التطبيقات الخاصة بك ومنع الطلبات الضارة من إتلاف خدمات واجهات برمجة التطبيقات بشكل فعال.
1. التحكم في الوصول بناءً على IP
التحكم في الوصول بناءً على IP هو الطريقة الأبسط والأكثر مباشرة، حيث يمكنه تقييد الوصول إلى واجهة برمجة التطبيقات الخاصة بك فقط للطلبات القادمة من عناوين محددة.
يمكنك استخدام مكون ip-restriction الخاص بـ APISIX لتمكين هذه الميزة، حيث يوفر خيارات تكوين مختلفة مثل قوائم عناوين IP المسموح بها أو المرفوضة، ونطاقات عناوين IP، والرسائل الخطأ التي يتم إرجاعها عند رفض الطلبات. يمكنك تكوين هذه الخيارات وفقًا لاحتياجاتك لتحقيق تحكم أكثر دقة في الوصول. من الجدير بالذكر أن التحكم في الوصول بناءً على IP قد يكون له بعض القيود، حيث يمكن تزوير عناوين IP أو مشاركتها. لذلك، عند استخدام مكون ip-restriction، من الأفضل دمجه مع مكونات تحكم في الوصول أخرى لتحسين أمان ومرونة نظامك.
2. التحكم في الوصول بناءً على مفتاح API
هذا النوع من التحكم في الوصول هو استراتيجية شائعة جدًا للتحكم في الوصول إلى واجهات برمجة التطبيقات. يعتمد مبدأه الأساسي على المصادقة والتفويض للطلبات من خلال مفتاح API يتم إنشاؤه مسبقًا، مما يسمح بإضافة آليات مصادقة سريعة إلى واجهات برمجة التطبيقات. ومع ذلك، من المهم حماية مفتاح API لمنع تسربه والتعرض لهجمات ضارة.
يمكن لمكون key-auth الخاص بـ APISIX إضافة آليات مصادقة بسهولة إلى واجهات برمجة التطبيقات الخاصة بك، عن طريق إضافة المفتاح إلى سلسلة الاستعلام أو الرأس للمصادقة عند إرسال الطلبات. في إصدار APISIX 3.1 وما بعده، يدعم أيضًا تشفير وتخزين مفاتيح API في etcd باستخدام تكوين encrypted storage fields data_encryption
، مما يعزز أمان واجهة برمجة التطبيقات الخاصة بك بشكل أكبر.
3. التحكم في الوصول بناءً على الرمز المميز (Token)
يتم تنفيذ هذه الطريقة عن طريق إضافة حقل مصادقة يحتوي على رمز مميز في رأس الطلب. الرمز المميز هو مفتاح، عادة ما يكون سلسلة أو رقم، يستخدم للتحقق مما إذا كان مرسل طلب واجهة برمجة التطبيقات لديه إذن للوصول إلى واجهة برمجة التطبيقات. عادةً ما يحتوي الرمز المميز على هوية المستخدم والأذونات، مما يسمح للخادم بتحديد ما إذا كان المستخدم لديه إذن الوصول عند بدء طلب واجهة برمجة التطبيقات واتخاذ قرارات التفويض أو الرفض المناسبة.
يوفر APISIX مكون jwt-auth لاستخدام هذه الاستراتيجية للتحكم في الوصول، حيث يدعم خيارات التكوين مثل موقع تخزين الرمز المميز، وفترة صلاحية الرمز المميز، وخوارزمية توقيع JWT، والمفاتيح. يمكنك تكوين هذه الخيارات وفقًا لاحتياجاتك لتلبية متطلبات المصادقة المختلفة.
4. التحكم في الوصول بناءً على مسار الطلب
يتم تحقيق التحكم في الوصول بناءً على مسار الطلب عن طريق تصفية ومطابقة مسارات الطلبات للتحكم في الوصول إلى واجهات برمجة التطبيقات أو الخدمات أو الموارد المحددة. تُستخدم هذه الاستراتيجية بشكل شائع في السيناريوهات التي تتطلب تحكمًا دقيقًا في الوصول إلى الموارد، مثل حماية البيانات الحساسة أو التحكم في وصول مستخدمين محددين إلى موارد محددة داخل النظام.
يدعم مكون uri-blocker الخاص بـ APISIX تكوين قوائم قواعد regex لاعتراض URIs طلبات المستخدمين، وتكوين rejected_code
وrejected_msg
لتحديد رمز حالة HTTP ونص الاستجابة الذي يتم إرجاعه بعد الاعتراض الناجح. هذا يسمح للمسؤولين بالتحكم بدقة في أذونات المستخدمين وتحسين أمان واجهات برمجة التطبيقات وقابليتها للتحكم.
5. سياسة التحكم في الوصول بناءً على قائمة التحكم في الوصول (ACL)
ACL (قائمة التحكم في الوصول) هي سياسة تحكم في الوصول تعتمد على القوائم وتستخدم للتحكم في أذونات الوصول للمستخدمين أو مجموعات المستخدمين إلى الموارد. يعتمد مبدأها الأساسي على تعريف قائمة ACL لكل مورد، حيث يتم سرد المستخدمين أو مجموعات المستخدمين المسموح لهم بالوصول إلى المورد. عندما يطلب مستخدم الوصول إلى المورد، يتم تحديد وصوله بناءً على قائمة ACL المقابلة.
في APISIX، يمكننا استخدام مكون consumer-restriction لتمكين هذه الميزة. يمكن للمسؤولين التحكم بسهولة في المستخدمين أو مجموعات المستخدمين الذين يمكنهم الوصول إلى موارد محددة ومنع المستخدمين غير المصرح لهم من إرسال طلبات إلى المناطق الحساسة، مما يتجنب تسرب البيانات الحساسة.
مقدمة السيناريو: التحكم في الوصول بدقة أكبر
في سيناريوهات التطبيق الواقعية، غالبًا ما ننفذ تحكمًا في الوصول بدقة أكبر للموارد التي تحتوي على بيانات حساسة. على سبيل المثال، لدينا الآن مستخدمين، A وB، يستخدمان نفس طرق المصادقة الداخلية، مثل key-auth أو basic-auth. نريد أيضًا تطبيق تحكم في الوصول بدقة أكبر على المستخدم B، ومنعه من الوصول إلى بعض واجهات برمجة التطبيقات.
يمكننا استخدام مكون consumer-restriction
الخاص بـ APISIX لبعض التحكم الأكثر دقة. يسمح لك هذا المكون بتعيين قيود الوصول بناءً على Route أو Service أو Consumer، ويدعم تكوين أربع قيم لخاصية type
:
consumer_name
: تقييد وصول Consumer إلى Route أو Service عن طريق سردusername
الخاص بـ Consumer في قائمة السماح أو الحظر.consumer_group_id
: تقييد وصول Consumer إلى Route أو Service عن طريق سردid
الخاص بمجموعة Consumer في قائمة السماح أو الحظر.service_id
: تقييد وصول Consumer إلى Service عن طريق سردid
الخاص بالخدمة في قائمة السماح أو الحظر. يجب استخدام هذا بالاقتران مع مكون تفويض.route_id
: تقييد وصول Consumer إلى Route عن طريق سردid
الخاص بالمسار في قائمة السماح أو الحظر.
في هذا السيناريو، يمكننا استخدام طريقتين للتكوين لمنع المستخدم B من الوصول إلى مورد واجهة برمجة تطبيقات محدد.
تعيين سياسة التحكم في الوصول في Route
- أولاً، نحتاج إلى إنشاء كائني Consumer على APISIX وتمكين مكون
basic-auth
، بأسماء userA وuserB.
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -i -d '
{
"username": "userA",
"plugins": {
"basic-auth": {
"username":"userA",
"password": "123456"
}
}
}'
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -i -d '
{
"username": "userB",
"plugins": {
"basic-auth": {
"username":"userB",
"password": "123456"
}
}
}'
- ثم نقوم بتمكين وتكوين خاصية
whitelist
الخاصة بـconsumer-restriction
على المسار الذي نريد تطبيق القيود عليه وإضافةusername
الخاص بـ Consumer userA الذي تم إنشاؤه مسبقًا. بهذه الطريقة، سيقبل المسار فقط الطلبات القادمة من userA.
curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -d '
{
"uri": "/get",
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
},
"plugins": {
"basic-auth": {},
"consumer-restriction": {
"whitelist": [
"userA"
]
}
}
}'
- إرسال طلبات وصول باستخدام userA وuserB بشكل منفصل.
curl -u userA:123456 http://127.0.0.1:9080/get -i
HTTP/1.1 200 OK
curl -u userB:123456 http://127.0.0.1:9080/get -i
HTTP/1.1 403 Forbidden
...
{"message":"The consumer_name is forbidden."}
تشير النتيجة إلى أن userB قد تم تقييد وصوله إلى مورد واجهة برمجة التطبيقات.
تعيين سياسات التحكم في الأذونات في Consumer
- أولاً، سنقوم بإعداد مسار يُسمى
forbidden-userB
، وتمكين مكونbasic-auth
.
curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -d '
{
"id": "forbidden-userB",
"uri": "/get",
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
},
"plugins": {
"basic-auth": {}
}
}'
- إنشاء كائني Consumer وتمكين مكون
basic-auth
. لاحظ أننا بحاجة إلى تكوين مكونconsumer-restriction
لتحسين سياسات التحكم في الأذونات لـ userB.
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -i -d '
{
"username": "userA",
"plugins": {
"basic-auth": {
"username":"userA",
"password": "123456"
}
}
}'
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: {YOUR_API_KEY}' -X PUT -i -d '
{
"username": "userB",
"plugins": {
"basic-auth": {
"username":"userB",
"password": "123456"
},
"consumer-restriction": {
"type": "route_id",
"blacklist": [
"forbidden-userB"
],
"rejected_code": 403
}
}
}'
- إرسال طلبات باستخدام userA وuserB بشكل منفصل.
curl -u userA:123456 http://127.0.0.1:9080/get -i
HTTP/1.1 200 OK
curl -u userB:123456 http://127.0.0.1:9080/get -i
HTTP/1.1 403 Forbidden
...
{"message":"The route_id is forbidden."}
من خلال فحص نتائج الاختبار، يمكننا التحقق من أن طلبات userB قد تم تقييدها بشكل فعال.
الخاتمة
تقدم هذه المقالة سياسات التحكم في الأذونات الشائعة الاستخدام في APISIX وتوضح كيفية تمكينها وتكوينها في APISIX باستخدام سيناريو كلاسيكي. التحكم في الأذونات هو استراتيجية شائعة في بوابات واجهات برمجة التطبيقات. لا يوفر APISIX فقط مجموعة شاملة من المكونات الجاهزة للاستخدام للمصادقة، ولكنه يوفر أيضًا دعمًا واسعًا في مجالات مثل الأمان، وإدارة حركة المرور، والمراقبة. من خلال اختيار وتكوين قواعد سياسات التحكم في الأذونات الخاصة بك، يمكنك بسهولة تعزيز أمان واجهات برمجة التطبيقات الخاصة بك.