আপনি সম্ভবত ইতিমধ্যেই এই পরিস্থিতির সম্মুখীন হচ্ছেন। কর্মীরা Microsoft 365, তারপর একটি বুকিং টুল, তারপর HR, তারপর একটি লাইন-অফ-বিজনেস অ্যাপ, তারপর কর্পোরেট WiFi-এ সাইন ইন করেন, প্রায়শই প্রতিটির জন্য আলাদা পদ্ধতি ব্যবহার করে। একটি হোটেল গ্রুপের হেড অফিসে এক সেট সিস্টেম এবং প্রপার্টিতে আরেকটি সেট সিস্টেম থাকে। একটি হাসপাতালে ক্লিনিকাল অ্যাপস, শেয়ার্ড ওয়ার্কস্টেশন এবং সেগমেন্টেড ওয়্যারলেস অ্যাক্সেস থাকে। একজন রিটেল অপারেটরের কর্মীরা বিভিন্ন স্টোর, ট্যাবলেট, POS এবং ব্যাক-অফিস ড্যাশবোর্ডের মধ্যে যাতায়াত করেন।
এই মিশ্রণটি দ্রুত ঘর্ষণ তৈরি করে। ব্যবহারকারীরা পাসওয়ার্ড ভুলে যান, IT টিম অ্যাকাউন্ট রিসেট করে এবং শেয়ার করা WiFi ক্রেডেনশিয়ালগুলি সরিয়ে ফেলার অনেক পরেও থেকে যায়। এর ফলাফল কেবল বিরক্তিই নয়। এটি কে, কোন ডিভাইস থেকে এবং কতক্ষণের জন্য কী অ্যাক্সেস করতে পারে তার উপর দুর্বল নিয়ন্ত্রণের সৃষ্টি করে।
ঠিক এখানেই single sign-on, বা SSO দরকারী হয়ে ওঠে। আপনি যদি what is single sign on খুঁজছেন, তবে সংক্ষিপ্ত উত্তরটি সহজ: এটি একজন ব্যবহারকারীকে একবার অথেন্টিকেট করতে এবং তারপর বারবার ক্রেডেনশিয়াল প্রবেশ না করেই একাধিক অনুমোদিত সিস্টেম অ্যাক্সেস করতে দেয়। আরও দরকারী উত্তরটি অপারেশনাল। SSO অ্যাপ্লিকেশনে অ্যাক্সেসের জন্য IT-কে একটি আইডেন্টিটি লেয়ার দেয় এবং সঠিক ডিজাইনে, এটি মানুষ এবং ডিভাইস কীভাবে নিরাপদ নেটওয়ার্কে যোগ দেয় তাও সমর্থন করতে পারে।
পাসওয়ার্ডের বিশৃঙ্খলার অবসান
বেশিরভাগ এন্টারপ্রাইজ পরিবেশ ইচ্ছাকৃতভাবে বিশৃঙ্খল হয়ে ওঠেনি। তারা সেভাবেই বড় হয়েছে। একটি ক্লাউড অ্যাপ থেকে পাঁচটি হয়েছে। একটি অফিস থেকে অনেক সাইট হয়েছে। IT-র জন্য একটি ওয়্যারলেস নেটওয়ার্ক থেকে কর্মী, অতিথি, ঠিকাদার এবং ডিভাইসগুলির জন্য আলাদা SSID হয়েছে।
এভাবেই পাসওয়ার্ডের বিস্তার শুরু হয়। একজন কর্মীর কোনো বাস্তব কাজ শুরু করার আগেই ইমেল, HR, সময়সূচী, ফাইল অ্যাক্সেস, অভ্যন্তরীণ ড্যাশবোর্ড এবং নেটওয়ার্ক অ্যাক্সেসের প্রয়োজন হতে পারে। IBM SSO-কে এমন একটি স্কিম হিসাবে বর্ণনা করে যেখানে ব্যবহারকারীরা একটি একক ক্রেডেনশিয়ালের সেট দিয়ে একবার লগ ইন করেন এবং একই সেশনের সময় একাধিক অ্যাপ্লিকেশন অ্যাক্সেস করেন, যা পরিষেবা প্রদানকারী এবং একটি আইডেন্টিটি প্রদানকারীর মধ্যে একটি বিশ্বস্ত সম্পর্কের মাধ্যমে সক্ষম হয়। IBM-এর single sign-on -এর ওভারভিউটি ক্লাউড গ্রহণ এবং দূরবর্তী কাজ ত্বরান্বিত হওয়ার সাথে সাথে ইউকে-র সংস্থাগুলির যা প্রয়োজন ছিল তার সাথে ঘনিষ্ঠভাবে মিলে যায়।
পাসওয়ার্ডের বিস্তার অপারেশনের কী ক্ষতি করে
যখন প্রতিটি অ্যাপ্লিকেশন নিজস্ব লগইন চায়, ব্যবহারকারীরা শর্টকাট নেওয়া শুরু করেন। তারা পাসওয়ার্ড পুনরায় ব্যবহার করেন। তারা ব্রাউজারে সেগুলি সংরক্ষণ করেন। তারা সহকর্মীদের কাছে “স্টাফ WiFi পাসওয়ার্ড” চান কারণ এটি IT-র জন্য অপেক্ষা করার চেয়ে দ্রুততর।
একজন এন্টারপ্রাইজ IT ম্যানেজারের জন্য, নিয়ন্ত্রণ সবচেয়ে গুরুত্বপূর্ণ বিষয়। আলাদা লগইনগুলি আলাদা অ্যাক্সেস আইল্যান্ড তৈরি করে এবং যখন লোকেরা ভূমিকা পরিবর্তন করে, ব্যবসা ছেড়ে চলে যায় বা একাধিক লোকেশন জুড়ে কাজ করে তখন সেই আইল্যান্ডগুলি পরিচালনা করা কঠিন হয়ে পড়ে।
পাসওয়ার্ডের বিশৃঙ্খলা খুব কমই একটি বড় ব্যর্থতা। এটি সাধারণত একশত ছোট অ্যাক্সেস সিদ্ধান্ত যা কেউ ধারাবাহিকভাবে পরিচালনা করতে পারে না।
কেন SSO পরিস্থিতি পরিবর্তন করে
SSO ব্যবহারকারীদের পরিচালনা করার জন্য প্রয়োজনীয় পাসওয়ার্ডের সংখ্যা কমিয়ে দেয়, যা লগইন অভিজ্ঞতাকে উন্নত করে এবং কেন্দ্রীয় নীতি এবং MFA এর সাথে যুক্ত হলে আরও শক্তিশালী নিরাপত্তা নিশ্চিত করে। এটি সেইসব বিতরণকৃত প্রতিষ্ঠানের বাস্তবতার সাথেও মানানসই যেখানে কর্মীদের ইমেল, HR, বুকিং টুলস, POS, অভ্যন্তরীণ অ্যাপস এবং সাইট পরিষেবা জুড়ে একটি লগইন প্রয়োজন।
ঠিক সেই একই যুক্তি এখন নেটওয়ার্ক অ্যাক্সেসকে রূপ দিচ্ছে। আপনি যদি ইতিমধ্যেই অ্যাপ্লিকেশনগুলির জন্য আইডেন্টিটি-ভিত্তিক অ্যাক্সেসের দিকে অগ্রসর হন, তবে একই ডিজাইন পদ্ধতির অংশ হিসাবে passwordless WiFi -এর দিকে নজর দেওয়া যুক্তিসঙ্গত, এটিকে একটি আলাদা সমস্যা হিসাবে দেখা ঠিক নয়।
প্রধান SSO ধারণাটি বোঝা
SSO প্রতিটি পৃথক অ্যাপ্লিকেশন থেকে প্রমাণীকরণকে সরিয়ে দেয় এবং এটিকে একটি বিশ্বস্ত আইডেন্টিটি সিস্টেমের সাথে স্থাপন করে। ব্যবহারকারী একবার সাইন ইন করেন, সেই আইডেন্টিটি যাচাই করা হয় এবং সংযুক্ত পরিষেবাগুলি অন্য পাসওয়ার্ড চাওয়ার পরিবর্তে সেই ফলাফলটি গ্রহণ করে।
এটি শুনতে সহজ মনে হতে পারে, তবে এর আসল মূল্য আর্কিটেকচারাল। আপনি বিশ্বাসযোগ্যতা কোথায় অবস্থিত তার পরিবর্তন করছেন।
প্রতিটি SSO প্রবাহে তিনটি পক্ষ
প্রতিটি SSO ডিজাইনের তিনজন অংশগ্রহণকারী থাকে এবং প্রত্যেকের কাজ আলাদা:
- ব্যবহারকারী কোনো অ্যাপ্লিকেশন, পরিষেবা বা নেটওয়ার্ক রিসোর্সে অ্যাক্সেস চান।
- Identity Provider বা IdP আইডেন্টিটি যাচাই করে এবং সাইন-ইন নীতি প্রয়োগ করে। যুক্তরাজ্যের সংস্থাগুলিতে সাধারণ উদাহরণের মধ্যে রয়েছে Microsoft Entra ID এবং Okta।
- Service Provider বা SP হলো সেই সিস্টেম যা ব্যবহারকারী অ্যাক্সেস করার চেষ্টা করছেন, যেমন Salesforce, একটি বুকিং প্ল্যাটফর্ম, একটি ইন্ট্রানেট বা অন্য কোনো ব্যবসায়িক সিস্টেম।
যে বিষয়টি প্রায়শই বিভ্রান্তির সৃষ্টি করে তা হলো বিশ্বাসযোগ্যতা। অ্যাপ্লিকেশনটিকে নিজে পাসওয়ার্ড সংগ্রহ এবং যাচাই করতে হবে না। এটি সেই কাজটি সঠিকভাবে করার জন্য IdP-এর উপর নির্ভর করে, তারপর ফলাফলটি গ্রহণ করে।
বিশ্বাসযোগ্য সম্পর্কটি আসলে কী বোঝায়
Auth0 এন্টারপ্রাইজ পরিভাষায় SSO-কে স্পষ্টভাবে ব্যাখ্যা করে: IdP ব্যবহারকারীকে একবার প্রমাণীকরণ করে, তারপর একটি সেশন আর্টিফ্যাক্ট বা টোকেন ইস্যু করে যা বিশ্বস্ত পরিষেবা প্রদানকারীরা পরবর্তী অ্যাক্সেসের জন্য যাচাই করে। বাস্তবে, ব্যবহারকারীকে IdP-তে রিডাইরেক্ট করা হয়, সেখানে প্রমাণীকৃত করা হয় এবং বারবার ক্রেডেনশিয়াল প্রম্পট ছাড়াই প্রতিটি অ্যাপে ফিরিয়ে আনা হয়। SaaS এবং অভ্যন্তরীণ সিস্টেম জুড়ে Entra ID ব্যবহার করা যুক্তরাজ্যের পরিবেশের জন্য Auth0-এর how single sign-on works সংক্রান্ত নির্দেশিকাটি বিশেষভাবে প্রাসঙ্গিক।
এটি সহজভাবে বোঝার একটি ব্যবহারিক উপায় হলো:
- একজন ব্যবহারকারী একটি অ্যাপ্লিকেশন খোলেন।
- অ্যাপ্লিকেশনটি পরীক্ষা করে দেখে যে কোনো বিশ্বস্ত IdP ইতিমধ্যেই সেই ব্যবহারকারীকে প্রমাণীকরণ করেছে কিনা।
- যদি কোনো সক্রিয় সেশন না থাকে, তবে ব্যবহারকারী IdP-এর মাধ্যমে সাইন ইন করেন।
- IdP পরিচয় নিশ্চিত করে এবং এমন প্রমাণ ফেরত দেয় যা অ্যাপ্লিকেশনটি যাচাই করতে পারে।
- অন্যান্য সংযুক্ত সিস্টেমগুলো সেশনের সময় সেই একই প্রমাণ গ্রহণ করতে পারে।
বাস্তব নিয়ম: SSO প্রতিটি সিস্টেমকে একটি প্ল্যাটফর্মে পরিণত করে না। এটি একাধিক সিস্টেমকে পরিচয় যাচাই করার জন্য একটি একক স্থান প্রদান করে।
কেন এটি ওয়েব অ্যাপের বাইরে গুরুত্বপূর্ণ
এখানেই SSO একটি SaaS সুবিধার চেয়েও বেশি কিছু হয়ে ওঠে। একবার পরিচয় কেন্দ্রীভূত হয়ে গেলে, ব্রাউজার সেশনের চেয়েও বেশি কিছুর জন্য একই মডেল ব্যবহার করা যেতে পারে। এটি আপনি কীভাবে অভ্যন্তরীণ পরিষেবাগুলোতে অ্যাক্সেস নিয়ন্ত্রণ করেন এবং সঠিক ডিজাইনে, ব্যবহারকারীরা কীভাবে কর্পোরেট ওয়্যারলেস নেটওয়ার্কে যুক্ত হন তাও রূপ দিতে পারে।
এটি IT অপারেশনের জন্য গুরুত্বপূর্ণ। একটি ফাইন্যান্স অ্যাপ, একটি VPN সেশন এবং একজন কর্মচারীর WiFi সংযোগ আলাদা পরিষেবা হতে পারে, তবে সেগুলো সবই একই প্রশ্ন দিয়ে শুরু হয়: এই ব্যবহারকারী কে এবং তাদের কি প্রবেশের অনুমতি দেওয়া উচিত? যখন Microsoft Entra ID বা Okta ধারাবাহিকভাবে সেই প্রশ্নের উত্তর দেয়, তখন অ্যাপ্লিকেশন এবং নেটওয়ার্ক এন্ট্রি পয়েন্ট উভয় জুড়েই অ্যাক্সেস পলিসি পরিচালনা করা সহজ হয়।
যেসব টিম এখনও শেয়ার করা পাসওয়ার্ড দিয়ে কর্মীদের WiFi পরিচালনা করছে, তাদের জন্য এটি একটি বড় পরিবর্তন। এমন একটি পাসওয়ার্ড দিয়ে ডিভাইস প্রমাণীকরণের পরিবর্তে যা সবাই জানে, আপনি একটি বিশ্বস্ত পরিচয় উৎসের বিপরীতে একজন ব্যক্তি বা একটি পরিচালিত ডিভাইস প্রমাণীকরণ করেন। এটি আপনাকে কঠোর নিয়ন্ত্রণ, আরও স্পষ্ট অডিট ট্রেইল এবং ভূমিকা পরিবর্তন বা কর্মসংস্থান শেষ হলে অ্যাক্সেস সরিয়ে নেওয়ার একটি পরিষ্কার উপায় দেয়।
SSO কীভাবে কাজ করে - মূল প্রোটোকলগুলো
ব্যবহারকারীর অভিজ্ঞতা সহজ দেখায়। এর অধীনে, SSO স্ট্যান্ডার্ড প্রোটোকলের উপর নির্ভর করে যা একটি অ্যাপ্লিকেশনকে অন্য কোথাও নেওয়া একটি পরিচয় সিদ্ধান্তের উপর বিশ্বাস রাখতে দেয়।
একজন এন্টারপ্রাইজ IT ম্যানেজারের জন্য, ব্যবহারিক প্রশ্নটি কেবল "SSO কী?" নয়। এটি হল "কীভাবে একটি সিস্টেম ব্যবহারকারীকে আবার লগ ইন করতে না বলে অন্য সিস্টেম থেকে প্রমাণ গ্রহণ করে?" উত্তরটি প্রোটোকলের একটি ছোট সেটের উপর নির্ভর করে যা অ্যাপ্লিকেশন, পরিচয় প্রদানকারী এবং কখনও কখনও ডিভাইসের মধ্যেই পরিচয় ডেটা স্থানান্তর করে।
এটি ব্রাউজার লগইনের বাইরেও গুরুত্বপূর্ণ। একটি SaaS অ্যাপ খোলার জন্য ব্যবহৃত একই ট্রাস্ট মডেল ব্যবহারকারীরা কীভাবে VPN, তারযুক্ত নেটওয়ার্ক এবং কর্পোরেট WiFi-এর সাথে সংযুক্ত হবে তাও প্রভাবিত করতে পারে যখন সেই অ্যাক্সেসের সিদ্ধান্তগুলো Microsoft Entra ID, Okta বা অন্য কোনও কেন্দ্রীয় পরিচয় উৎসের সাথে সংযুক্ত থাকে।
সহজ বাংলায় SAML
এন্টারপ্রাইজ SSO-তে এখনও SAML 2.0 সাধারণ, বিশেষ করে প্রতিষ্ঠিত SaaS প্ল্যাটফর্ম এবং লাইন-অফ-বিজনেস সিস্টেমের জন্য।
SAML অ্যাপ্লিকেশন এবং পরিচয় প্রদানকারীর মধ্যে বিশ্বস্ত পরিচয় বিবৃতি পাস করে কাজ করে। একজন ব্যবহারকারী একটি অ্যাপ্লিকেশন খোলার চেষ্টা করেন। অ্যাপ্লিকেশনটি তাদের IdP-তে রিডাইরেক্ট করে। IdP ব্যবহারকারীকে প্রমাণীকরণ করে এবং একটি ডিজিটালি স্বাক্ষরিত দাবি ফেরত পাঠায়। অ্যাপ্লিকেশনটি সেই স্বাক্ষর পরীক্ষা করে, পরিচয় দাবিটি গ্রহণ করে এবং একটি সেশন তৈরি করে।
সেই ফ্লোটি এমন পরিবেশের জন্য উপযুক্ত যেখানে ব্রাউজারটি বেশিরভাগ কাজ করছে এবং অ্যাপ্লিকেশনটি একটি আনুষ্ঠানিক, মানক-ভিত্তিক আদান-প্রদান আশা করে।
SAML প্রায়শই এর জন্য অত্যন্ত উপযুক্ত:
- Enterprise SaaS যেমন HR, ফিন্যান্স, বা লিগ্যাসি ব্যবসায়িক অ্যাপ্লিকেশন
- Browser-based workflows যেখানে ব্যবহারকারীরা একটি ওয়েব সেশনের মাধ্যমে সিস্টেম অ্যাক্সেস করেন
- Central policy enforcement যখন IT টিম অথেন্টিকেশন পরিচালনা করার জন্য একটি একক স্থান চায়
সহজ ভাষায় OAuth এবং OIDC
OAuth 2.0 মূলত কোনো ক্রেডেনশিয়ালের সম্পূর্ণ বিবরণ শেয়ার না করেই কোনো রিসোর্সে সীমিত অ্যাক্সেস দেওয়ার একটি উপায় হিসেবে শুরু হয়েছিল। এটি মূলত অথরাইজেশনের সাথে সম্পর্কিত।
OpenID Connect, বা OIDC, OAuth 2.0-এর উপরে আইডেন্টিটি বা পরিচয় যোগ করে। এটি আধুনিক অ্যাপ্লিকেশনগুলোকে ব্যবহারকারীর পরিচয় নিশ্চিত করার একটি স্ট্যান্ডার্ড উপায় প্রদান করে এবং একই সাথে টোকেন-ভিত্তিক অ্যাক্সেস প্যাটার্ন ব্যবহার করতে সাহায্য করে। যদি SAML সাধারণত পুরোনো ব্রাউজার-কেন্দ্রিক SaaS-এর জন্য উপযুক্ত হয়, তবে OIDC সাধারণত নতুন ওয়েব অ্যাপ, মোবাইল অ্যাপ এবং API-চালিত পরিষেবাগুলোর সাথে আরও ভালো কাজ করে।
ব্যবহারিক ক্ষেত্রে, আধুনিক ডেভেলপমেন্ট টিমগুলোর কাছে OIDC ব্যবহারে অনেক বেশি স্বাচ্ছন্দ্য বোধ হয় কারণ টোকেনগুলো ফ্রন্ট-এন্ড অ্যাপ, ব্যাক-এন্ড সার্ভিস এবং মোবাইল ক্লায়েন্ট জুড়ে চমৎকারভাবে কাজ করে। IT টিমের জন্য এর অর্থ হলো অ্যাপ্লিকেশনটি প্রথাগত ব্রাউজার সেশন না হলেও জটিল কোনো বিকল্প পথ খোঁজার প্রয়োজন হয় না।
OIDC সাধারণত উপযোগী:
- আধুনিক ক্লাউড অ্যাপ্লিকেশন
- মোবাইল এবং সিঙ্গেল-পেজ অ্যাপ
- API-ভারী এনভায়রনমেন্ট যেখানে টোকেনগুলো ইতিমধ্যে ডিজাইনের অংশ
Kerberos সম্পর্কিত একটি সংক্ষিপ্ত নোট
SSO আলোচনার ক্ষেত্রে আপনি হয়ত Kerberos-এর নামও শুনে থাকবেন। Kerberos প্রথাগত Active Directory এনভায়রনমেন্ট এবং অন-প্রেমিস Windows অথেন্টিকেশনের সাথে ঘনিষ্ঠভাবে যুক্ত। এটি অভ্যন্তরীণ এন্টারপ্রাইজ স্টেটের ক্ষেত্রে এখনও প্রাসঙ্গিক, বিশেষ করে যেখানে ডোমেইন-যুক্ত ডিভাইস এবং লিগ্যাসি অ্যাপ্লিকেশনগুলো এখনও ব্যবহৃত হচ্ছে।
তা সত্ত্বেও, বর্তমানের অনেক SSO প্রজেক্ট ক্লাউড এবং হাইব্রিড পরিষেবা জুড়ে ফেডারেশন আইডেন্টিটির উপর বেশি জোর দেয়। সেই ক্ষেত্রে, SAML এবং OIDC সাধারণত বেশি গুরুত্ব পায় কারণ এগুলো SaaS প্ল্যাটফর্ম এবং বাইরে থেকে অ্যাক্সেসযোগ্য পরিষেবাগুলোর সাথে আরও সহজে সংযুক্ত হতে পারে।
এক নজরে SAML বনাম OIDC
| ফিচার | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| প্রধান ভূমিকা | এন্টারপ্রাইজ ওয়েব অ্যাপ্লিকেশনের জন্য অথেন্টিকেশন | OIDC এর মাধ্যমে আইডেন্টিটি যুক্ত করে অথরাইজেশন |
| সাধারণ ব্যবহারের ক্ষেত্র | প্রতিষ্ঠিত SaaS এবং ব্রাউজার-ভিত্তিক এন্টারপ্রাইজ অ্যাপ | আধুনিক ওয়েব অ্যাপ, মোবাইল অ্যাপ, APIs |
| ফরমেট | XML-ভিত্তিক অ্যাসারশনস | টোকেন-ভিত্তিক ফ্লো |
| স্বাভাবিক ফ্লো | IdP-তে রিডাইরেক্ট করুন, অথেন্টিকেট করুন, সাইন করা অ্যাসারশন ফেরত দিন | রিডাইরেক্ট বা টোকেন ফ্লো, তারপর অ্যাপ আইডেন্টিটি এবং অ্যাক্সেসের জন্য টোকেন ব্যবহার করে |
| সবচেয়ে উপযুক্ত | প্রথাগত এন্টারপ্রাইজ SSO ইন্টিগ্রেশন | নতুন ক্লাউড-নেটিভ এবং অ্যাপ-কেন্দ্রিক আর্কিটেকচার |
একজন IT ম্যানেজারের জন্য যা গুরুত্বপূর্ণ
ডিজাইন সংক্রান্ত সিদ্ধান্তের তুলনায় প্রোটোকলের নাম কম গুরুত্বপূর্ণ। আপনার চারটি অপারেশনাল প্রশ্নের স্পষ্ট উত্তর প্রয়োজন:
- কোন অ্যাপগুলো SAML বা OIDC সমর্থন করে
- কোন IdP আপনার কেন্দ্রীয় কন্ট্রোল প্লেন হিসেবে কাজ করবে
- সেশন টাইমআউট, MFA এবং কন্ডিশনাল অ্যাক্সেস কীভাবে কার্যকর করা হবে
- স্টাফ WiFi সহ নেটওয়ার্ক অ্যাক্সেস একই সোর্সের বিপরীতে আইডেন্টিটি যাচাই করবে কিনা
শেষ পয়েন্টটিই হলো যেখানে ইনফ্রাস্ট্রাকচার টিমের জন্য SSO বিশেষ উপকারী হয়ে ওঠে। আপনার ওয়্যারলেস প্ল্যাটফর্ম যদি আপনার SaaS এস্টেটের মতো একই আইডেন্টিটি লেয়ার ব্যবহার করতে পারে, তবে লগইন পেজ থেকে নেটওয়ার্ক এজ পর্যন্ত অ্যাক্সেস পলিসি আরও সামঞ্জস্যপূর্ণ হয়ে ওঠে। এটাই অন্যতম কারণ যে অনেক টিম অ্যাক্সেস কন্ট্রোল এবং অপারেশনের জন্য single sign-on এর সুবিধাগুলো পর্যালোচনা করার পাশাপাশি কেবল ওয়েব অ্যাপ লগইন নয়, আইডেন্টিটি-ব্যাকড WiFi অথেন্টিকেশনের দিকেও নজর দিতে শুরু করে।
সুবিধা এবং সিকিউরিটি ট্রেড-অফগুলো বিবেচনা করা
SSO-কে প্রায়ই ব্যবহারকারীর সুবিধাজনক ফিচার হিসেবে উপস্থাপন করা হয়। এটি এর গুরুত্বকে খাটো করে দেখায়। সঠিকভাবে করা হলে, এটি একটি অ্যাক্সেস কন্ট্রোল মডেল যা একই সাথে ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে পারে এবং অপারেশনাল সিকিউরিটি জোরদার করতে পারে।
Okta উল্লেখ করে যে SSO-এর টেকনিক্যাল সুবিধা কেবল সুবিধাই নয়। এটি পাসওয়ার্ডের সংখ্যা এবং বারবার লগইনের ঘটনা কমায় যা হেল্প-ডেস্কের লোড এবং ব্যবহারকারীর বিরক্তি দূর করে। single sign-on সিকিউরিটি সম্পর্কে Okta-এর ওভারভিউতে এমন একটি পয়েন্টও তুলে ধরা হয়েছে যা আর্কিটেক্টদের কাছে গুরুত্বপূর্ণ: যদি IdP সেশনটি ইনভ্যালিড হয়ে যায়, তবে সংযুক্ত অ্যাপ্লিকেশনগুলো পরবর্তী টোকেন চেকের সময় অ্যাক্সেস প্রত্যাখ্যান করতে পারে।
কোথায় ব্যবসায়িক মূল্য দৃশ্যমান হয়
প্রথম সুবিধাটি হলো সহজ অ্যাক্সেস। ব্যবহারকারীরা একবার লগইন করেন, দ্রুত কাজ শুরু করতে পারেন এবং অথেন্টিকেশনকে প্রতিদিনের বাধা হিসেবে দেখা বন্ধ করেন।
দ্বিতীয়টি হলো শক্তিশালী কেন্দ্রীয় নিয়ন্ত্রণ। প্রতিটি অ্যাপ্লিকেশনের ভেতরে সেটিংস খোঁজার পরিবর্তে IT টিম একটি আইডেন্টিটি লেয়ার থেকে MFA, কন্ডিশনাল অ্যাক্সেস, সেশন পলিসি এবং রিভোকেশন প্রয়োগ করতে পারে।
তৃতীয় সুবিধাটি হলো জয়নার, মুভার এবং লিভারদের আরও সহজভাবে পরিচালনা করা। আইডেন্টিটি যখন কেন্দ্রীয়ভাবে থাকে, তখন অনবোর্ডিং এবং অফবোর্ডিং আরও সামঞ্জস্যপূর্ণ হয়। এটি অন্যতম কারণ যে টিমগুলো single sign-on এর সুবিধাগুলো এক্সপ্লোর করার সময় প্রায়ই SSO প্রজেক্টগুলোকে আরও ব্যাপক আইডেন্টিটি গভর্নেন্স কাজের সাথে যুক্ত করে।
যে ট্রেড-অফগুলোকে আপনার গুরুত্ব সহকারে নেওয়া উচিত
এখানে একটি সত্যিকারের "কিস টু দ্য কিংডম" (সবকিছুর নিয়ন্ত্রণ হারিয়ে ফেলার) উদ্বেগ রয়েছে। যদি কোনো আক্রমণকারী ব্যবহারকারীর প্রাথমিক সাইন-ইন হ্যাক করে, তবে এর প্রভাবের পরিধি অনেক বড় হতে পারে কারণ একটি অ্যাকাউন্ট অনেক সিস্টেমে অ্যাক্সেস প্রদান করতে পারে।
এখানে সহনশীলতার ঝুঁকিও রয়েছে। IdP অনুপলব্ধ হলে, সংযুক্ত পরিষেবাগুলিতে অ্যাক্সেস ব্যাহত হতে পারে। এবং ইন্টিগ্রেশন সবসময় নিখুঁত হয় না। পুরোনো অ্যাপ, নির্দিষ্ট বিষয়ের সিস্টেম এবং স্থানীয় নেটওয়ার্ক পরিষেবাগুলি সর্বদা একটি আধুনিক SSO মডেলের সাথে পুরোপুরি খাপ খায় না।
সঠিক প্রশ্নটি এটি নয় যে SSO-এর ক্ষেত্রে কোনো আপস করতে হয় কিনা। বরং প্রশ্নটি হলো আপনি সেই আপসগুলো কেন্দ্রীয়ভাবে পরিচালনা করতে চান নাকি ডজন ডজন সংযোগহীন আপস পরিচালনা করে যেতে চান।
সাধারণ প্রশমন ব্যবস্থা
একটি স্তরযুক্ত পদ্ধতি ব্যবহার করুন:
- MFA, শর্তাধীন অ্যাক্সেস, ডিভাইসের নির্ভরযোগ্যতা এবং শক্তিশালী অ্যাডমিন নিয়ন্ত্রণের মাধ্যমে IdP-কে কঠোরভাবে সুরক্ষিত করুন।
- সহনশীলতার পরিকল্পনা করুন যাতে একটি IdP সমস্যা সমগ্র প্রতিষ্ঠান-ব্যাপী স্থবিরতার কারণ না হয়ে দাঁড়ায়।
- উচ্চ-মূল্যের অ্যাপ এবং স্পষ্ট ব্যবহারকারী গোষ্ঠী দিয়ে শুরু করে ধাপে ধাপে রোল আউট করুন।
- নিয়মিতভাবে অ্যাক্সেস পর্যালোচনা করুন যাতে পুরোনো এনটাইটেলমেন্টগুলি প্রয়োজনের পরেও দীর্ঘকাল টিকে না থাকে।
একটি দুর্বল SSO রোলআউট সমস্যাগুলিকে কেন্দ্রীভূত করতে পারে। একটি শক্তিশালী রোলআউট নিয়ন্ত্রণকে কেন্দ্রীভূত করে।
ওয়েব অ্যাপের বাইরে SSO - নেটওয়ার্ক এবং WiFi অ্যাক্সেস
বেশিরভাগ নিবন্ধ SaaS-এ গিয়েই শেষ হয়ে যায়। এটি দরকারী, কিন্তু অপূর্ণাঙ্গ। বাস্তব পরিবেশে, কর্মীদের কেবল অ্যাপ অ্যাক্সেসের প্রয়োজন হয় না। সাইটে পৌঁছানোর পর, একটি পরিচালিত ল্যাপটপ সংযুক্ত করার সময়, কোনো শাখায় ট্যাবলেট খোলার সময় বা বিভিন্ন সম্পত্তির মধ্যে রোম করার সময় তাদের নিরাপদ নেটওয়ার্ক অ্যাক্সেসের প্রয়োজন হয়।
ঠিক এখানেই SSO আলোচনাটি আরও আকর্ষণীয় হয়ে ওঠে। যে একই আইডেন্টিটি প্রোভাইডার Microsoft 365, HR সিস্টেম বা অভ্যন্তরীণ ড্যাশবোর্ডগুলির অ্যাক্সেস পরিচালনা করে, সেটি ওয়্যারলেস প্রমাণীকরণ নীতিগুলির জন্য সত্যের উৎস (source of truth) হয়ে উঠতে পারে।
Optimal IdM তাদের single sign-on adoption সংক্রান্ত আলোচনায় রিপোর্ট করেছে যে, উত্তর আমেরিকার ৫২% IT পেশাদার আইডেন্টিটি ম্যানেজমেন্টের জন্য SSO ব্যবহার করেন। একাধিক ভেন্যু বা সম্পত্তি থাকা ইউকে-র প্রতিষ্ঠানগুলির জন্য, এই পরিপক্কতা অত্যন্ত গুরুত্বপূর্ণ কারণ কর্মীদের প্রায়শই বারবার লগইন না করেই শেয়ার করা সিস্টেমে নিরাপদ অ্যাক্সেসের প্রয়োজন হয়।
অ্যাপ SSO এবং নেটওয়ার্ক আইডেন্টিটি সম্পর্কিত, তবে অভিন্ন নয়
পাঠকদের জন্য একটি সাধারণ বিভ্রান্তির জায়গা হলো, অ্যাপ্লিকেশনের জন্য SSO এবং আইডেন্টিটি-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস একে অপরের সাথে সম্পর্কিত ধারণা হলেও, এগুলো একই পদ্ধতি নয়।
অ্যাপ SSO বলতে সাধারণত বোঝায় ব্যবহারকারী IdP-এর মাধ্যমে একবার প্রমাণীকরণ করেন এবং একটি টোকেন বা সেশন পান যা সংযুক্ত অ্যাপ্লিকেশনগুলি দ্বারা গৃহীত হয়। অন্যদিকে, নেটওয়ার্ক অ্যাক্সেস প্রায়শই অন্যান্য নিয়ন্ত্রণগুলি ব্যবহার করে, যেমন ডিভাইস সার্টিফিকেট, ওয়্যারলেস প্রমাণীকরণ পদ্ধতি, ডিরেক্টরি-ব্যাকড নীতি এবং পস্চার বা ট্রাস্ট চেক।
তাদেরকে যা লিঙ্ক করে তা হলো আইডেন্টিটি সোর্স। Entra ID বা Okta যদি ইতিমধ্যেই জানে যে ব্যবহারকারী কে, তারা কোন গ্রুপের অন্তর্ভুক্ত এবং তাদের ডিভাইসটি ম্যানেজড কিনা, তাহলে আপনি সেই আইডেন্টিটি কনটেক্সট ব্যবহার করে সিদ্ধান্ত নিতে পারেন যে তাদের স্টাফ নেটওয়ার্কে যুক্ত হওয়া উচিত কিনা।
কর্পোরেট WiFi-তে এটি দেখতে কেমন লাগে
একটি পরিপক্ক ডিজাইনে, স্টাফদের কোনো শেয়ারড WiFi পাসওয়ার্ড টাইপ করতে হয় না। তাদের অর্গানাইজেশন-ম্যানেজড ডিভাইসটি এনরোলড, ট্রাস্টেড এবং তাদের আইডেন্টিটির সাথে যুক্ত থাকে। যখন তারা বিল্ডিংয়ে প্রবেশ করে, ডিভাইসটি সার্টিফিকেট-ভিত্তিক বা সমতুল্য এন্টারপ্রাইজ অথেন্টিকেশন ব্যবহার করে উপযুক্ত সিকিউর SSID-এর সাথে কানেক্ট হয়ে যায়।
এটি অপারেশনাল দিক থেকে অনেক কিছু পরিবর্তন করে:
- শেয়ারড পাসওয়ার্ড অদৃশ্য হয়ে যায়, তাই একটি লিক হওয়া ক্রিডেনশিয়াল পুরো ওয়ার্কফোর্স নেটওয়ার্ককে প্রভাবিত করে না।
- অ্যাক্সেস রোল-অ্যাওয়ার হয়ে ওঠে, কারণ পলিসি আইডেন্টিটি গ্রুপগুলোকে অনুসরণ করতে পারে।
- রিভোকেশন দ্রুততর হয়, কারণ ডিরেক্টরি অ্যাক্সেস পরিবর্তিত হলে, নেটওয়ার্ক অ্যাক্সেসও তার সাথে পরিবর্তিত হতে পারে।
- রোমিং সহজতর হয়, বিশেষ করে মাল্টি-সাইট এস্টেট জুড়ে যেখানে ব্যবহারকারীরা সর্বত্র একই অভিজ্ঞতা আশা করেন।
হসপিটালিটি, রিটেইল এবং হেলথকেয়ারে এটি কেন গুরুত্বপূর্ণ
এই সেক্টরগুলো এজ কেসে ভরপুর। আপনার এখানে শিফট ওয়ার্কার, শেয়ারড ডিভাইস, এজেন্সি স্টাফ, রোমিং টিম এবং কর্পোরেট, সেমি-কর্পোরেট ও গেস্ট অ্যাক্সেসের চাহিদার একটি ধ্রুবক মিশ্রণ রয়েছে।
একটি হোটেল গ্রুপ হয়তো একটি স্টাফ আইডেন্টিটি দিয়ে PMS অ্যাক্সেস, ব্যাক-অফিস অ্যাপস এবং সমস্ত প্রোপার্টি জুড়ে সিকিউর ইন্টারনাল WiFi পরিচালনা করতে চাইতে পারে। একটি রিটেইল চেইন হয়তো ম্যানেজড হ্যান্ডহেল্ড ডিভাইসগুলোকে স্টোর WiFi-এর সাথে অটোমেটিক কানেক্ট করতে চাইতে পারে যেখানে গেস্ট ট্রাফিক আইসোলেটেড থাকবে। একটি হেলথকেয়ার প্রোভাইডার হয়তো ক্লিনিক্যাল ব্যবহারকারী, ভিজিটর এবং কানেক্টেড ডিভাইসের মধ্যে আরও শক্তিশালী বিভাজন চাইতে পারে।
এখানেই network access control solutions আলোচনার কেন্দ্রে আসে। এগুলো অ্যাপ্লিকেশন লেয়ার থেকে নেটওয়ার্ক লেয়ারে আইডেন্টিটি পলিসি প্রসারিত করতে সাহায্য করে।
যেখানে Purple খাপ খায়
একটি ব্যবহারিক অপশন হলো Purple, যা স্টাফ এবং মাল্টি-টেন্যান্ট এনভায়রনমেন্টের জন্য আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং সাপোর্ট করে, যার মধ্যে শেয়ারড পাসওয়ার্ডের উপর নির্ভর না করে সিকিউর অ্যাক্সেসের জন্য Entra ID, Google Workspace এবং Okta-র সাথে ইন্টিগ্রেশন অন্তর্ভুক্ত রয়েছে। এই ধরনের পদ্ধতি তখন উপযোগী হয় যখন আপনি চান যে অ্যাপ আইডেন্টিটি এবং নেটওয়ার্ক আইডেন্টিটি একই সোর্স অফ ট্রুথ থেকে কাজ করুক।
আপনার ইন্ডাস্ট্রিতে SSO - ব্যবহারিক কেস স্টাডি
SSO-এর মূল্য বোঝার সবচেয়ে সহজ উপায় হলো আর্কিটেকচার ডায়াগ্রাম না দেখে দৈনন্দিন কাজের দিকে তাকানো।
হসপিটালিটি
একজন হোটেল অপারেশনস ম্যানেজার দিনের কাজ একটি প্রোপার্টিতে শুরু করেন এবং অন্যটিতে শেষ করেন। উভয় লোকেশনেই তার শিডিউলিং, একটি প্রোপার্টি ম্যানেজমেন্ট সিস্টেম, শেয়ারড ডকুমেন্টস এবং ইন্টারনাল WiFi-তে অ্যাক্সেসের প্রয়োজন হয়।
SSO-এর মাধ্যমে, সেই পরিচয় তাদের অনুসরণ করে। তারা একবার সাইন ইন করেন এবং অনুমোদিত সিস্টেমগুলো সেই সেশনটিকে সনাক্ত করে। সংস্থা যদি নেটওয়ার্ক অ্যাক্সেসকে একই পরিচয়ের উৎসের সাথে যুক্ত করে, তবে তাদের পরিচালিত ডিভাইসটি কোনো কর্মী কর্তৃক ডিউটি ম্যানেজারকে সর্বশেষ পাসওয়ার্ড টেক্সট না করেই স্টাফ WiFi-এ যুক্ত হতে পারে।
রিটেইল
একজন রিজিওনাল ম্যানেজার একটি ট্যাবলেট নিয়ে দোকানে প্রবেশ করেন। তাদের সাথে সাথে সেলস ড্যাশবোর্ড, স্টক টুল এবং অভ্যন্তরীণ যোগাযোগের অ্যাপগুলোর প্রয়োজন হয়।
একটি খণ্ডিত সেটআপে, প্রতিটি স্টপে আরেকটি লগইন প্রম্পট, আরেকটি মেয়াদোত্তীর্ণ পাসওয়ার্ড বা সহায়তার জন্য আরেকটি কল বোঝাতে পারে। একটি পরিচয়-নেতৃত্বাধীন মডেলে, ট্যাবলেটটি নিখুঁতভাবে প্রমাণীকরণ করে, অ্যাক্সেস ব্যবহারকারীর ভূমিকা প্রতিফলিত করে এবং কাজ শেষ করার জন্য স্টোরের কর্মীদের স্থানীয় শংসাপত্রগুলো ভাগ করতে হয় না।
ভালো SSO অ্যাক্সেসকে অদৃশ্য করে না। এটি বৈধ অ্যাক্সেসকে অনুমানযোগ্য করে তোলে।
হেলথকেয়ার
একজন ক্লিনিশিয়ান একটি শিফট শুরু করেন এবং মূল সিস্টেমে দ্রুত, নিয়ন্ত্রিত অ্যাক্সেস প্রয়োজন হয়। তারা দিনের বেলা ওয়ার্কস্টেশন, শেয়ার্ড ডিভাইস এবং সীমাবদ্ধ নেটওয়ার্ক সেগমেন্টের মধ্যে চলাফেরা করতে পারেন।
এখানে, SSO অনুমোদিত অ্যাপ্লিকেশনগুলোতে বারবার সাইন-ইন কমাতে সাহায্য করে, যখন পরিচয়-ভিত্তিক নেটওয়ার্ক নিয়ন্ত্রণগুলো সঠিক ব্যবহারকারী এবং ডিভাইসগুলো সঠিক ওয়্যারলেস পরিবেশের সাথে সংযোগ স্থাপন করতে সহায়তা করে। এই বিভাজনটি গুরুত্বপূর্ণ। ক্লিনিকাল অ্যাক্সেস, গেস্ট অ্যাক্সেস এবং ডিভাইস অ্যাক্সেস সব একইভাবে পরিচালিত হওয়া উচিত নয়।
মাল্টি-টেন্যান্ট প্রপার্টি এবং ক্যাম্পাস
শিক্ষার্থী আবাসন, ব্যবসায়িক কেন্দ্র এবং মিশ্র-ব্যবহারের প্রপার্টিগুলোতে, কর্মী এবং বাসিন্দারা প্রায়শই একই শারীরিক অবকাঠামোতে সহাবস্থান করে তবে তাদের কখনই একই অ্যাক্সেস মডেল শেয়ার করা উচিত নয়।
কর্মীদের বিল্ডিং সিস্টেম, সাপোর্ট টুল এবং অভ্যন্তরীণ প্রশাসনিক অ্যাপের প্রয়োজন হতে পারে। বাসিন্দা বা ভাড়াটেদের নির্ভরযোগ্য সংযোগের প্রয়োজন, তবে অপারেশনাল প্ল্যাটফর্মে অ্যাক্সেসের প্রয়োজন নেই। এই প্রসঙ্গে, পরিচয় ডিজাইন সবচেয়ে বেশি গুরুত্বপূর্ণ। SSO কর্মীদের অ্যাক্সেসকে সমর্থন করতে পারে, যখন পৃথক নেটওয়ার্ক পরিচয় নীতিগুলো ভাড়াটে এবং গেস্ট ট্রাফিককে বিচ্ছিন্ন রাখে।
SSO বাস্তবায়ন এবং সর্বোত্তম অনুশীলন
একটি সফল SSO প্রকল্প একটি সিদ্ধান্তের মাধ্যমে শুরু হয়: আপনার নিয়ন্ত্রণ প্লেন হিসাবে কাজ করবে এমন পরিচয় প্রদানকারীকে বেছে নিন। অনেক সংস্থার জন্য এটি হল Microsoft Entra ID বা Okta, কারণ সেই প্ল্যাটফর্মগুলো ইতিমধ্যেই ব্যবহারকারীর লাইফসাইকেল, MFA এবং ডিভাইস নীতির কাছাকাছি অবস্থান করে।
রোলআউট ধাপে ধাপে হওয়া উচিত। সবচেয়ে গুরুত্বপূর্ণ অ্যাপ্লিকেশন এবং সবচেয়ে বেশি উপকৃত হওয়ার সম্ভাবনা রয়েছে এমন ব্যবহারকারী গোষ্ঠীগুলো দিয়ে শুরু করুন। সদৃশ অ্যাকাউন্টগুলো পরিষ্কার করুন, ভূমিকার গ্রুপগুলো সঠিকভাবে সংজ্ঞায়িত করুন এবং আপনি পরিধি প্রসারিত করার আগে সেশনের আচরণ পরীক্ষা করুন।
সবচেয়ে গুরুত্বপূর্ণ নিয়ন্ত্রণগুলো
কয়েকটি অনুশীলন একটি সাধারণ ডেমো এবং একটি দীর্ঘস্থায়ী স্থাপনার মধ্যে পার্থক্য তৈরি করে:
- প্রাথমিক সাইন-ইন পয়েন্টে MFA বাধ্যতামূলক করুন। যদি একটি লগইন অনেক সংস্থানে অ্যাক্সেস প্রদান করতে পারে, তবে সেই লগইনের আরও শক্তিশালী সুরক্ষার প্রয়োজন।
- অবিলম্বে বাতিলের চারপাশে লিভার প্রক্রিয়া তৈরি করুন। কেন্দ্রীয় পরিচয় কেবল তখনই সাহায্য করে যদি অ্যাকাউন্টের পরিবর্তনগুলো দ্রুত কার্যকর হয়।
- ভূমিকা অনুযায়ী অ্যাক্সেস পর্যালোচনা করুন। কেউ যদি এখনও কার অ্যাক্সেস আছে তা পরীক্ষা না করে, তবে SSO অতিরিক্ত-অধিকারের বিষয়টি এড়িয়ে যাওয়া সহজ করে তুলতে পারে।
- IdP বিঘ্নের জন্য পরিকল্পনা করুন। আপনার আইডেন্টিটি সার্ভিস উপলব্ধ না থাকলে কী ঘটবে এবং কোন সিস্টেমে ফলব্যাক হ্যান্ডলিং প্রয়োজন তা জেনে রাখুন।
কখন SSO সঠিক টুল নয় তা জানুন
অনেক সাধারণ ব্যাখ্যামূলক আলোচনায় এই বিষয়টি বাদ পড়ে যায়। OneLogin বাস্তব-ক্ষেত্রের ডেপ্লয়মেন্টে কর্মী SSO এবং গেস্ট বা ডিভাইস অ্যাক্সেসের মধ্যে একটি ক্রমবর্ধমান পার্থক্য লক্ষ্য করে, এবং how single sign-on works -এর ব্যাখ্যায় ক্রেতাদের জন্য একটি দরকারী প্রশ্ন জিজ্ঞাসা করে: কখন SSO ভুল টুল, এবং অ্যাপ লগইনের পরিবর্তে কখন আইডেন্টিটি নেটওয়ার্ক অ্যাক্সেসে প্রয়োগ করা উচিত?
এটি WiFi ডিজাইনের ক্ষেত্রে গুরুত্বপূর্ণ। কর্মীদের প্রায়শই আইডেন্টিটি-লিঙ্কড, পলিসি-চালিত অ্যাক্সেস ব্যবহার করা উচিত। গেস্টদের সাধারণত আরও হালকা, সহজ এবং পৃথক কিছুর প্রয়োজন হয়। কর্মী SSO-এর মাধ্যমে প্রতিটি অ্যাক্সেস সংক্রান্ত সমস্যাকে জোর করে সমাধান করার চেষ্টা করলে যেখানে প্রয়োজন নেই সেখানেও জটিলতা তৈরি হয়।
আপনি যদি একটি বিস্তৃত অ্যাক্সেস কৌশলের অংশ হিসাবে SSO পর্যালোচনা করেন, তবে একই আলোচনায় অ্যাপ, কর্মী WiFi, গেস্ট অনবোর্ডিং, শেয়ার করা ডিভাইস এবং রিভোকেশন ওয়ার্কফ্লো অন্তর্ভুক্ত করুন। সাধারণত সেখানেই সবচেয়ে বড় অপারেশনাল সুবিধাগুলো দেখা যায়।
আপনি যদি অ্যাপ, কর্মী WiFi, গেস্ট অনবোর্ডিং, বা মাল্টি-টেন্যান্ট নেটওয়ার্ক জুড়ে অ্যাক্সেস পুনর্বিবেচনা করেন, তবে Purple দেখে নেওয়া যেতে পারে। এটি আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং প্রদান করে যা Entra ID, Okta, এবং Google Workspace-এর মতো প্ল্যাটফর্মের সাথে কাজ করতে পারে, যা টিমগুলোকে শেয়ার করা পাসওয়ার্ড এবং জটিল Captive Portal সরিয়ে কর্মী, গেস্ট এবং বাসিন্দাদের জন্য নিয়ন্ত্রিত অ্যাক্সেস চালু করতে সাহায্য করে।
