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

এই স্থাপনা সম্পর্কে সরবরাহকারীকে যা নিশ্চিত করতে হবে

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

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

প্রমাণ করুন দ্বিতীয় উপাদানটি সত্যিই দ্বিতীয় উপাদান

প্রমাণক ও যাচাইয়ের প্রবাহের নাম দিন, এবং বলুন প্রতিটি ধাপ কোন পরিচয় প্রতিষ্ঠা করে। পরপর দুইবার পাসওয়ার্ড চাওয়া দ্বিতীয় উপাদান নয়, আর পাসওয়ার্ডের সঙ্গে এককালীন কোড সেবার সঙ্গে বাঁধা ক্রিপ্টোগ্রাফিক প্রমাণকের চেয়ে ভিন্ন দাবি। বাক্সের লেবেল নয়, আপনি যে প্রবাহ কিনছেন সেটি লিখুন।

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

কিছু ভাঙার আগেই পাসের শর্ত লিখুন

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

Acceptance stageEvidence to keepPass condition
EnrolmentEnrolment record with the device type and the identity usedA new device enrols once, and nobody else can enrol it afterwards
Sign-in with the second factorSession record naming both factors and the gateway identity that was checkedThe session carries the expected identity and the gateway certificate validated
Denial of an unapproved destinationLog line from the control that refused the flow, with the policy nameThe flow is refused and the refusal is attributable to one control
Revocation of one userRevocation timestamp and the sessions that survived itThe named user is out and unaffected users keep working
Restore from configuration backupRestored version plus a probe of a revoked identityThe revision matches the backup and revoked identities stay revoked

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

সরাসরি গেটওয়েতে নয়, কপিতে মহড়া করুন

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

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

আপনার দল যে কাজের ভার চালাবে তা মাপুন

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

শিটটি সম্পূর্ণ যখন প্রতিটি ধাপের একটি নথি থাকে এবং প্রতিটি নথির একটি তারিখ থাকে। কেউ রক্ষণাবেক্ষণ করে এমন অ্যাপ্লায়েন্স, প্রতিটি সারির প্রমাণসহ, টিক দেওয়া বাক্সের দীর্ঘতম তালিকার চেয়ে ভিন্ন একটি কেনাকাটা।

সম্পর্কিত নিবন্ধ