মাইক্রোসার্ভেস এবং গ্রাহকদের জন্য অনুমোদন এবং প্রমাণীকরণ সিস্টেম

15

আমরা আমাদের সংস্থা সিস্টেমকে একটি মাইক্রো-পরিষেবা ভিত্তিক সিস্টেমে রিফ্যাক্টর করার পরিকল্পনা করি। এই মাইক্রো-পরিষেবাগুলি আমাদের নিজস্ব অভ্যন্তরীণ সংস্থার অ্যাপ্লিকেশন এবং তৃতীয় পক্ষের অংশীদাররা প্রয়োজনে ব্যবহার করবে। বুকিংয়ের জন্য একটি, পণ্য ইত্যাদির জন্য একটি

কীভাবে ভূমিকা এবং স্কোপগুলি পরিচালনা করবেন তা আমরা নিশ্চিত নই। ধারণাটি হ'ল অ্যাডমিনস, এজেন্টস এবং এন্ড-ইউজারদের মতো 3 টি বেসিক ব্যবহারকারীর ভূমিকা তৈরি করা এবং যদি প্রয়োজন হয় তবে গ্রাহক অ্যাপ্লিকেশনগুলিকে সূক্ষ্ম-সুরক্ষিত করতে দিন।

প্রশাসকরা ডিফল্টরূপে (তাদের সংস্থার জন্য) সমস্ত সংস্থান তৈরি করতে, আপডেট করতে, পড়তে এবং মুছতে পারে।
এজেন্টরা তাদের সংস্থার জন্য ডেটা তৈরি করতে, আপডেট করতে এবং পড়তে পারে।
শেষ ব্যবহারকারীরা ডেটা তৈরি করতে, আপডেট করতে, মুছতে এবং পড়তে পারে তবে এজেন্ট বা প্রশাসকদের মতো একই পয়েন্টগুলি অ্যাক্সেস করতে পারে না। তারা ডেটা তৈরি বা সংশোধন করতে সক্ষম হবেন, এজেন্ট বা প্রশাসক হিসাবে কেবল একই স্তরে নয়। উদাহরণস্বরূপ, শেষ ব্যবহারকারীরা তাদের অ্যাকাউন্টের তথ্য আপডেট করতে বা পড়তে পারবেন, এজেন্টের মতো এটি তাদের পক্ষে এটি করতে সক্ষম হবে তবে তারা অ্যাডমিন নোটগুলি দেখতে বা আপডেট করতে পারে না।

ধরা যাক যে ডিফল্টরূপে এজেন্টরা তাদের সংস্থার জন্য প্রতিটি সংস্থান তৈরি করতে, পড়তে এবং আপডেট করতে পারে এবং এটিই তাদের সর্বোচ্চ সুযোগ যা তাদের টোকেন / সেশনের জন্য অনুরোধ করা যেতে পারে তবে ক্লায়েন্টের (এপিআই গ্রাহক) অ্যাপ্লিকেশন বিকাশকারীরা সিদ্ধান্ত নিয়েছে যে তাদের এজেন্টগুলির মধ্যে একটি পড়ুন এবং শুধুমাত্র নির্দিষ্ট সংস্থান তৈরি করুন।

আমাদের অভ্যন্তরীণ সুরক্ষায় এটি হ্যান্ডেল করার জন্য কি আরও ভাল অনুশীলন, এবং তাদের আমাদের ডাটাবেসে সেই ডেটাটি লিখতে দেওয়া হোক, বা ক্লায়েন্টরা স্বল্প হ'ল একটি টোকেনের অনুরোধ করে অভ্যন্তরীণভাবে এটি পরিচালনা করতে দিন এবং তাদের ডেটাবেজে কোন এজেন্টের কোন সুযোগ থাকবে তা তাদের লিখতে দিন let ? এইভাবে আমাদের কেবল টোকেন স্কোপগুলি ট্র্যাক করতে হবে।

এর কুফলটি হ'ল আমাদের টিমকে আমাদের অভ্যন্তরীণ অ্যাপ্লিকেশনগুলিতে সূক্ষ্ম সুরযুক্ত অ্যাক্সেস ব্যবস্থা তৈরি করতে হবে।

এই চিন্তার এই পদ্ধতিতে, মাইক্রো পরিষেবাগুলি এবং তাদের অনুমোদনের সিস্টেমগুলিকে ক্লায়েন্টগুলির প্রয়োজনের সাথে উদ্বিগ্ন করা উচিত নয়, কারণ তারা কেবল গ্রাহক এবং সিস্টেমের অংশ নয় (যদিও তাদের মধ্যে কিছু গ্রাহক আমাদের নিজস্ব অভ্যন্তরীণ অ্যাপ্লিকেশন)?

এই প্রতিনিধি একটি ভাল পদ্ধতির হয়?

— রবার্ট
সূত্র

14

প্রমাণীকরণ এবং অনুমোদন সর্বদা ভাল বিষয়

আমি আপনাকে বোঝানোর চেষ্টা করব যে আমি যে বর্তমান বহু-ভাড়াটে পরিষেবাটিতে কাজ করছি তাতে অনুমোদনের বিষয়টি কীভাবে হয়। জেএসএন ওয়েব টোকেন ওপেন স্ট্যান্ডার্ড ব্যবহার করে প্রমাণীকরণ এবং অনুমোদন টোকেন ভিত্তিক। পরিষেবাটি একটি REST API উন্মুক্ত করে যা কোনও ধরণের ক্লায়েন্ট (ওয়েব, মোবাইল এবং ডেস্কটপ অ্যাপ্লিকেশন) অ্যাক্সেস করতে পারে। যখন কোনও ব্যবহারকারী সাফল্যের সাথে প্রমাণীকৃত হয় তখন পরিষেবাটি একটি অ্যাক্সেস টোকেন সরবরাহ করে যা সার্ভারে প্রতিটি অনুরোধে প্রেরণ করা আবশ্যক।

সুতরাং সার্ভার অ্যাপ্লিকেশনটিতে আমরা কীভাবে ডেটা উপলব্ধি করি এবং চিকিত্সা করি তার উপর ভিত্তি করে আমরা কিছু ধারণাটি ব্যবহার করি যা আমরা ব্যবহার করি।

সংস্থান : এটি কোনও ইউনিট বা ডেটা গ্রুপ যা কোনও ক্লায়েন্ট পরিষেবার মাধ্যমে অ্যাক্সেস করতে পারে। আমরা যে সমস্ত সংস্থাগুলি নিয়ন্ত্রণ করতে চাই সেগুলিতে আমরা একটি নাম নিযুক্ত করি। উদাহরণস্বরূপ, পরবর্তী শেষ পয়েন্টের নিয়ম থাকা আমরা সেগুলি নিম্নলিখিত হিসাবে নাম রাখতে পারি:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

সুতরাং আসুন আমরা এইভাবে বলি যে আমাদের পরিষেবায় এখন পর্যন্ত আমাদের তিনটি সংস্থান রয়েছে; product, paymentএবংorder ।

ক্রিয়া : এটি এমন একটি ক্রিয়াকলাপ যা কোনও উত্সে সঞ্চালিত হতে পারে, যেমন, পড়া, তৈরি, আপডেট, মুছুন ইত্যাদি just কেবল ক্লাসিক সিআরইউডি অপারেশন হওয়া প্রয়োজন নয় follow, উদাহরণস্বরূপ, আপনি যদি একটি ক্রিয়াকলাপের নামকরণ করতে পারেন তবে যদি আপনি ওয়েবসকেট ব্যবহার করে কোনও ধরণের তথ্য প্রচার করে এমন একটি পরিষেবা প্রকাশ করতে চাই।

ক্ষমতা : একটি actionউপর একটি সঞ্চালন করার ক্ষমতা resource। এই ক্ষেত্রে; পণ্যগুলি পড়ুন, পণ্য তৈরি করুন ইত্যাদি just এটি মূলত কেবল একটি সংস্থান / ক্রিয়া জুড়ি। তবে আপনি এটিতে একটি নাম এবং বিবরণ যুক্ত করতে পারেন।

ভূমিকা : এমন একাধিক দক্ষতার সেট যা ব্যবহারকারীর মালিকানা পেতে পারে। উদাহরণস্বরূপ, কোনও ভূমিকার Cashier"পেমেন্ট পড়ুন", "অর্থ প্রদান" তৈরি Sellerকরতে বা কোনও ভূমিকাতে "পঠন পণ্য", "পড়ার ক্রম", "আপডেট অর্ডার", "অর্ডার মুছুন" এর ক্ষমতা থাকতে পারে।

অবশেষে, একজন ব্যবহারকারী তার কাছে বিভিন্ন ভূমিকা নিযুক্ত করতে পারেন।

ব্যাখ্যা

আমি আগেই বলেছি, আমরা জেএসএন ওয়েব টোকেন এবং ব্যবহারকারীর ধারণক্ষমতা টোকেনের পে-লোডে ঘোষণা করি। সুতরাং, ধরা যাক, একটি ছোট খুচরা দোকানে আমাদের একই সাথে ক্যাশিয়ার এবং বিক্রেতার ভূমিকা রয়েছে with পে-লোডটি এর মতো দেখাবে:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

আপনি যেমন scopesদাবিতে দেখতে পাচ্ছেন আমরা তার পরিবর্তে ভূমিকার (ক্যাশিয়ার, বিক্রেতা) নাম নির্দিষ্ট করি না, কেবল সম্পদ এবং জড়িত ক্রিয়াগুলি নির্দিষ্ট করা হয়। যখন কোনও ক্লায়েন্ট একটি শেষ পয়েন্টে একটি অনুরোধ প্রেরণ করে, অ্যাক্সেস টোকনে প্রয়োজনীয় সংস্থান এবং ক্রিয়া রয়েছে কিনা সেবার পরিষেবাটি পরীক্ষা করা উচিত। উদাহরণস্বরূপ, GETশেষ পয়েন্টে একটি অনুরোধ /payments/88সফল হবে, তবে DELETEএকই সমাপ্তি বিন্দুতে একটি অনুরোধ ব্যর্থ হতে হবে।

কীভাবে সংস্থানসমূহের গোষ্ঠীকরণ ও নামকরণ করা এবং কীভাবে কার্য এবং দক্ষতা সংজ্ঞায়িত ও নামকরণ করা যায় তা বিকাশকারীরা সিদ্ধান্ত নেবেন।

সেই ভূমিকাগুলি কী কী এবং কী কী ক্ষমতাগুলি এই ভূমিকা রাখবে তা হ'ল গ্রাহকদের সিদ্ধান্ত।

অবশ্যই, ব্যবহারকারী এবং গ্রাহক (ভাড়াটে) কে টোকেন জারি করে শনাক্ত করার জন্য আপনাকে অবশ্যই পেলোডে অতিরিক্ত সম্পত্তি যুক্ত করতে হবে।

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

এই পদ্ধতির সাহায্যে আপনি আপনার পরিষেবায় যে কোনও ব্যবহারকারীর অ্যাকাউন্টের অ্যাক্সেসকে সূক্ষ্ম-টিউন করতে পারেন। এবং সর্বাধিক গুরুত্বপূর্ণ, আপনার প্রশ্নে উল্লেখ করার সাথে সাথে আপনাকে বিভিন্ন পূর্বনির্ধারিত এবং স্থির ভূমিকা যেমন অ্যাডমিন, এজেন্টস এবং শেষ ব্যবহারকারীদের তৈরি করতে হবে না। একটি সুপার ব্যবহারকারী এমন এক ব্যবহারকারী হবেন যা তার দ্বারা নির্ধারিত roleসমস্ত resourcesএবং তার actionsসাথে থাকা পরিষেবার মালিকানাধীন user

এখন, যদি 100 টি সংস্থান থাকে এবং আমরা এমন একটি ভূমিকা চাই যা সমস্ত বা প্রায় সকলকে অ্যাক্সেস দেয়? আমাদের টোকেন পেওলড বিশাল হবে। এটি সংস্থানগুলি সম্পদ নেস্ট করে এবং কেবল অ্যাক্সেস টোকেন স্কোপে প্যারেন্ট রিসোর্স যুক্ত করে সমাধান করা হয়।

অনুমোদন একটি জটিল বিষয় যা প্রতিটি প্রয়োগের প্রয়োজনের উপর নির্ভর করে সমাধান করতে হবে।

— মিসো
সূত্র

ধন্যবাদ তোমার উত্তরের জন্য. এটি খুব সহায়ক। আমি ব্যবহারকারী প্রতি একাধিক ভূমিকা সম্পর্কিত একটি প্রশ্ন আছে। আপনার কি এমন কোনও মামলা রয়েছে যেখানে ভূমিকার অনুমতিগুলি ওভারল্যাপ করে? যেমন ক্যাশিয়ার আছে payment:[read], বিক্রেতার কাছে রয়েছে payment: [create]। আপনি কি এক্ষেত্রে সামগ্রিক অনুমতি গ্রহণ করেন?

— রবার্ট

আপনার যদি বারবার সক্ষমতার সাথে ভূমিকা থাকে তবে (resource/action)আপনাকে অবশ্যই তাদের মার্জ করতে হবে। যদি অনুমতিগুলি ওভারল্যাপ হয় তবে আপনাকে অবশ্যই এগুলিকে একত্রিত করতে হবে। ধারণাটি হ'ল টোকেনের অনুমতিপ্রাপ্ত সংস্থানসমূহ এবং ক্রিয়াকলাপগুলি সংজ্ঞায়িত করা, গ্রাহকদের অনুমোদনের সাথে মোকাবিলার জন্য আরও জটিল পদ্ধতিতে প্রদত্ত বিমূর্ততা হিসাবে কেবল ভূমিকাগুলি ছেড়ে দেওয়া।

— Miso

1

কোন ব্যবহারকারী যদি কেবলমাত্র ওডাব্লুএন এর সংস্থানগুলিতে পদক্ষেপ নেওয়ার ক্ষমতা রাখতে পারে তবে কী হবে। উদাহরণস্বরূপ কোনও ব্যাংক অ্যাকাউন্টের মতো, অবশ্যই "bank_account": ["পড়ুন", "আপডেট"] এটি নির্দিষ্ট করে না। এছাড়াও, কোনও মাইক্রোসার্ভেসিস সিস্টেমে অনুমোদনের প্রক্রিয়াটি ঠিক কোথায় ঘটে? একটি কেন্দ্রীভূত অনুমোদনের সার্ভারে, বা প্রতিটি পরিষেবা তার নিজস্ব অনুমোদন করে?

— রকেটস্পেসার

@rocketspacer। এজন্যই userটোকেনটির পেডলোডে সম্পত্তি রয়েছে। আমি যেভাবে কোনও ব্যবহারকারীর মালিকানাধীন কোনও সংস্থানটি লক করছি userতা হল ইউআরএলটিতে দাবি ম্যাপিং । উদাহরণস্বরূপ: /users/coyote/back-accountকেবলমাত্র userসমান দাবির সাথে টোকেনের মাধ্যমে অ্যাক্সেসযোগ্য হবে coyote। আমি আশা করি যে সাহায্য।

— Miso

3

আমি মনে করি যে যাই হোক না কেন, আপনি আপনার পরিষেবাগুলি এমন একটি প্রমাণীকরণ টোকেন গ্রহণ করতে চান যা ব্যবহারকারীদের যাচাই করার জন্য আপনি লিখেছেন এমন একটি প্রমাণীকরণ পরিষেবা সরবরাহ করে। এটি আপনার মাইক্রো সার্ভিসেসের অপব্যবহার রোধ করার জন্য সবচেয়ে সরল / নিরাপদ উপায়। এছাড়াও, সাধারণভাবে, আপনি যদি ক্লায়েন্টের একটি ভাল অভিজ্ঞতা অর্জন করতে চান তবে আপনার সমালোচনামূলক বৈশিষ্ট্যগুলি নিজে প্রয়োগ করা উচিত এবং আপনার দেওয়া বৈশিষ্ট্যগুলি কার্যকরভাবে প্রয়োগ হয়েছে কিনা তা নিশ্চিত করার জন্য পুরোপুরি পরীক্ষা করা উচিত।

যেহেতু সমস্ত কলকারীদের আপনার মাইক্রোসার্ফেসিসের প্রমাণ সরবরাহ করা দরকার যে তারা প্রমাণীকৃত হয়েছে, সুতরাং আপনি সেই প্রমাণীকরণের সাথে অনুমতিও বেঁধে রাখতে পারেন। আপনি যদি কোনও ব্যবহারকারীকে একটি স্বেচ্ছাসেবী অ্যাক্সেস গোষ্ঠীর সাথে বেঁধে রাখার দক্ষতা সরবরাহ করেন (বা গ্রুপগুলি যদি আপনি অভিনব হতে চান তবে যদিও অনুমতিগুলি বনাম বিয়োগফলকে এখানে মোকাবেলা করা আরও শক্ত) এক্স একটি অনাকাঙ্ক্ষিত অপারেশন করতে সক্ষম হয়েছিল। যে কোনও ক্ষেত্রে প্রত্যেককে প্রতিটি পরিষেবার জন্য অ্যাক্সেস তালিকার চেকিং করতে হবে, তাই এটি আপনিও হতে পারেন। এটি এমন একটি বিষয় যা খুব সহজেই সমস্ত পরিষেবাগুলির শুরুতে কোড করা হবে (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) যাতে আপনি এটি করতে পারেন এবং ব্যবহারকারীর গোষ্ঠীগুলি নিজেরাই নজর রাখতে পারেন। এটি সত্য যে আপনার কোনও অনুমতি গ্রুপ ম্যানেজার থাকতে হবে এবং এটি ব্যবহারকারীর পরিচালনা ইউআইতে কাজ করতে হবে (ব্যবহারকারীর অনুমতিগুলির জন্য নতুন গ্রুপ তৈরি করুন / ব্যবহার করুন) আপনি সংজ্ঞাটি সম্পাদনা করার সময় কোনও গ্রুপে আবদ্ধ ব্যবহারকারীদের অবশ্যই বিভ্রান্তি এড়াতে তালিকাবদ্ধ করুন । তবে, এটি কোনও কঠিন কাজ নয়। সমস্ত পরিষেবাদির জন্য কেবল মেটাডেটা আছে এবং গ্রুপ এবং পরিষেবাগুলির মধ্যে মথিংটিকে অ্যাথ টোকেন হ্যান্ডলিংয়ের জন্য সন্ধান করুন।

ঠিক আছে, সুতরাং এখানে কয়েকটি বিশদ রয়েছে, তবে আপনার প্রতিটি ক্লায়েন্ট যে এই কার্যকারিতাটি চান তাদের যে কোনও ক্ষেত্রে এটি কোড করতে হবে এবং আপনি যদি তিন স্তরের ব্যবহারকারীর অনুমতি সমর্থন করেন তবে আপনি কেবল এটির ব্যবহারকারীর অ্যাক্সেসের জন্য বাড়িয়ে দিতে পারেন গোষ্ঠী। সম্ভবত বেস গ্রুপ অনুমতি এবং ব্যবহারকারীর নির্দিষ্ট অনুমতিগুলির মধ্যে একটি যৌক্তিক ছেদটি সঠিক সমষ্টি হবে, তবে আপনি যদি অ্যাডমিন, এজেন্ট, শেষ-ব্যবহারকারীর বেস অনুমতিগুলির বেস অনুমতিগুলি যোগ করতে এবং সরিয়ে নিতে সক্ষম হন তবে আপনাকে করতে হবে অনুমতি গোষ্ঠীতে ব্যবহারযোগ্য ত্রি-রাষ্ট্রীয় পতাকা: অনুমতি যুক্ত করুন, অনুমতি অস্বীকার করুন, ডিফল্ট অনুমতি দিন এবং অনুমতিগুলি যথাযথভাবে একত্র করুন।

(একটি দ্রষ্টব্য হিসাবে, যদি আপনি কথোপকথনের উভয় প্রান্তের সুরক্ষা সম্পর্কে উদ্বিগ্ন হন তবে এসএসএল বা দ্বি-মুখী এসএসএল এর মতো কিছুতেই এটি হওয়া উচিত you আপনি যদি কোনও আক্রমণকারীকে এই টোকেনগুলি "ফাঁস" করেন তবে সে এমনভাবে প্রবেশ করবে যেন সে ' ডি একটি পাসওয়ার্ড ফাটল।)

— BenPen
সূত্র

অবকাঠামো এবং বাস্তবায়ন সম্পর্কে চিন্তা করার সময়, আমি ক্লায়েন্টের অভিজ্ঞতার কথা পুরোপুরি ভুলে গিয়েছিলাম .. আমি নিয়মের একটি সেট তৈরি করার ধারণাটি পছন্দ করি যা আমাদের ব্যবসায়ের সাথে আরও বেশি হবে। অ্যাডমিনস, এজেন্টস এবং এন্ড-ইউজাররা খুব জেনেরিক এবং আমরা আরও বেশি ব্যবহারকারীর প্রকার প্রয়োগ করার পরিকল্পনা করি যা আরও বর্ণনামূলক এবং আমাদের ব্যবসায় এবং সর্বব্যাপী ভাষার সাথে আবদ্ধ।

— রবার্ট

আমি শেষ বাক্যে "অ্যান্ডেড" টাইপো সংশোধন করতে পারিনি কারণ আমি এটি বের করতে পারি নি।

— তুলাইনস কর্ডোভা

এটি অগত্যা কোনও টাইপ নয়, তবে আমি এটি আরও পরিষ্কার করে দেব ..

— বেনপেন

1

আমার দৃষ্টিভঙ্গি এখানে আপনার দুটি পছন্দ আছে।

যদি আপনার কেবল একই অ্যাপ্লিকেশনটিতে মূলত কনফিগারযোগ্য অ্যাক্সেস থাকা দরকার থাকে তবে পরিষেবাগুলি চেক করার অনুমতি নিন এবং আপনার গ্রাহকদের একটি ইন্টারফেস দিন যা তাদের প্রতিটি ভূমিকার জন্য দেওয়া অনুমতিগুলি পরিবর্তন করতে দেয়। এটি বেশিরভাগ ব্যবহারকারীকে ডিফল্ট রোল সেটআপ ব্যবহার করতে সহায়তা করে, যা 'সমস্যা' গ্রাহকরা ভূমিকাটি সামঞ্জস্য করতে বা তাদের প্রয়োজন অনুসারে নতুন তৈরি করতে পারে।
আপনার গ্রাহকরা যদি তাদের নিজস্ব অ্যাপ্লিকেশন বিকাশ করে থাকেন তবে তাদের নিজস্ব মধ্যবর্তী এপি চালু করা উচিত। যা অ্যাডমিন হিসাবে আপনার সাথে সংযুক্ত হয় তবে আপনার পরিষেবাদিগুলিতে ফোন করার আগে তাদের নিজস্ব কাস্টম লেখার প্রয়োজনীয়তার বিপরীতে আগত অনুরোধটি পরীক্ষা করে

— ইওয়ান
সূত্র

1

সুরক্ষা বিবেচনা

যদি আমি আপনার নকশাটি ভালভাবে বুঝতে পারি তবে আপনি ক্লায়েন্টের পক্ষে কিছু সংস্থান অ্যাক্সেস কন্ট্রোল প্রক্রিয়াটি অর্পণ করার মনস্থ করেছেন, অর্থাত কোনও গ্রাহক অ্যাপ্লিকেশন ব্যবহারকারী দেখতে পাবে এমন আইটেম হ্রাস করে। আপনার অনুমানটি হ'ল:

মাইক্রো-পরিষেবাগুলি এবং তাদের অনুমোদনের সিস্টেমগুলিকে ক্লায়েন্টগুলির প্রয়োজনীয়তা নিয়ে বিরক্ত করা উচিত নয়, কারণ তারা কেবল গ্রাহক এবং সিস্টেমের অংশ নয়

আমি এখানে গুরুতর ব্যবসায়ের জন্য দুটি গুরুতর সমস্যা দেখছি:

যদি কিছু দুর্বৃত্ত ব্যবহারকারী সেখানে উপস্থিত হন (উদাহরণস্বরূপ আপনার অংশীদারের উদ্ভিদের কোনও ক্ষেত্রে) ক্লায়েন্ট অ্যাপটিকে বিপরীত ইঞ্জিনিয়াররা এবং এপিআই সম্পর্কে সন্ধান করে, তার সংস্থা ক্লায়েন্টের উপর যে বিধিনিষেধ আরোপ করেছে এবং তা আপনার কোম্পানির ক্ষতি করার জন্য সেই তথ্য ব্যবহার করে? আপনার সংস্থা ক্ষতির দাবি করবে, তবে পার্টনার সংস্থা যুক্তি দিবে যে আপনি যথেষ্ট পরিমাণে আপনার ডেটা সুরক্ষিত করার উপায় দেননি।
সাধারণত, এটি কেবল সময়ের প্রশ্ন যে সংবেদনশীল ডেটা অপব্যবহার করা হয় (বা নিরীক্ষণটি ঝুঁকিটি আবিষ্কার করবে) এবং আপনার পরিচালনা সেই ডেটার আরও কঠোরভাবে নিয়ন্ত্রণের জন্য জিজ্ঞাসা করবে।

এ কারণেই আমি এই জাতীয় ইভেন্টগুলির পূর্বাভাস দেওয়ার এবং অনুমোদনের অনুরোধগুলির যত্ন নেওয়ার পরামর্শ দেব। আপনি প্রথম দিকে পুনর্নির্ধারণের পর্যায়ে রয়েছেন এবং পরবর্তীকালের চেয়ে এগুলি আপনার আর্কিটেকচারে বিবেচনায় নেওয়া আরও সহজ হবে implement

আপনি যদি আপনার বর্তমান অবস্থান অনুসরণ করেন তবে কমপক্ষে আপনার তথ্য সুরক্ষা কর্মকর্তার সাথে পরামর্শ করুন।

কীভাবে এটি বাস্তবায়ন করা যায়

আপনার কৌশলটি আছে:

এইভাবে, আমাদের কেবলমাত্র টোকেন স্কোপগুলি ট্র্যাক করতে হবে।

ঠিক আছে, আপনি ক্লায়েন্টের দ্বারা নির্বাচিত কিছু সাধারণ টোকেন ব্যবহার করার পরিকল্পনা করছেন। আবার আমার চোখে একটি দুর্বলতা, কারণ কিছু ক্লায়েন্ট আপনার নিয়ন্ত্রণের বাইরে চলে যেতে পারে।

আপনি ইতিমধ্যে জেডাব্লুটি ব্যবহার করেন বা অন্য কোনও কৌশল ব্যবহার করেন কিনা তা আমি জানি না । তবে আপনি যদি জেডাব্লুটিটি ব্যবহার করেন, আপনার কাছে একটি পরিচয় টোকেন থাকতে পারে যা ব্যবহারকারীর পরিচয় বহন করে (এবং এমনকী দ্বিতীয় টোকেন যা নিরাপদে উত্পন্ন অ্যাপটিকে সনাক্ত করে, যা আপনাকে ঘরে বসে ক্লায়েন্ট এবং বহিরাগত ক্লায়েন্টদের মধ্যে আস্থার স্তরকে আলাদা করতে দেয় )।

আপনি যদি একটি microservice স্থাপত্য জন্য যেতে মনস্থ করা হিসেবে আমি সুপারিশ করতে চাই পার্থক্য amke ব্যবহারকারী পরিচালনা এবং প্রমাণীকরণ প্রক্রিয়া (যা একটি ডেডিকেটেড পরিসেবা হিসাবে চালানো উচিত) এবং প্রবেশাধিকার নিয়ন্ত্রণ (যা প্রতিটি microservice নির্দিষ্ট মধ্যে, এবং করা উচিত তাদের প্রত্যেকের দ্বারা স্থানীয়ভাবে পরিচালনা করা হবে)। অবশ্যই কিছু প্রশাসক ক্লায়েন্টের ব্যবহারের সহজতার জন্য কয়েকটি পরিষেবা জুড়ে একটি বিস্তৃত ওভারভিউ দেওয়া উচিত)।

— ক্রিস্টোফ
সূত্র

1

এখানে খুব ভাল পরামর্শ। আমি দ্বিতীয় টোকেন সহ ধারণাটি পছন্দ করি।

— রবার্ট

1

এখানে, একটি সংক্ষিপ্ত উত্তরও আছে। আপনি আপনার "ক্লায়েন্ট" কে নিজের কাছে অফার করতে চান এমন সমস্ত মূল বৈশিষ্ট্যগুলি কার্যকর করা উচিত । আপনি ইতিমধ্যে ব্যবহারকারীর প্রমাণীকরণ করছেন যেহেতু ক্লায়েন্টরা তাদের অনুমতি হিসাবে ব্যবহারকারীদের যেমন মৌলিক আচরণ যুক্ত করা সমস্যাযুক্ত বলে মনে হচ্ছে; আপনি যদি এটি প্রয়োগের জন্য ক্লায়েন্টের কাছে রেখে দেন তবে আপনি একই অনুমতি কোডের একাধিক বাস্তবায়ন "সমর্থন" করতে পারেন। যদিও আপনি এটি "মালিকানাধীন না" থাকলেও তাদের কোডগুলিতে বাগ থাকবে এবং আপনি চান যে আপনার ক্লায়েন্টরা যে কার্যকারিতাটি প্রত্যাশা করেছিলেন, যুক্তির মধ্যে রয়েছে, তাই আপনি কোনও ক্লায়েন্টের যে সমস্যা রয়েছে তার সমাধানের জন্য আপনি সমর্থন করেন। একাধিক কোড ঘাঁটি সমর্থন করা মজাদার নয়।

— BenPen
সূত্র