আমি কীভাবে কোনও প্রোডাকশন ডেটাবেস দিয়ে দুর্ঘটনাক্রমে জ্যাকিং রোধ করতে পারি?


31

সম্প্রতি, আমার বিকাশকারী ঘটনাক্রমে প্রোডাক্টে একটি ডাটাবেস পুনরুদ্ধার করার চেষ্টা করেছিল, যখন তার মঞ্চের অনুলিপিটি পুনরুদ্ধার করা উচিত ছিল। এটি করা সহজ, ডিবি নামগুলি সমান, যেমন, গ্রাহক নাম_সেটেজিং বনাম গ্রাহকনাম_প্রডাকশন।

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

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

অনুশীলন, কনফিগারেশন এবং এটি কীভাবে প্রতিরোধ করা যায় তার নিয়ন্ত্রণগুলির ক্ষেত্রে আমি কিছু পরামর্শ শুনতে পছন্দ করি।


25
বিকাশকারীদের উত্পাদন ডেটাবেজে লেখার অ্যাক্সেস বা পছন্দসই কোনও অ্যাক্সেস থাকা উচিত নয় ।
মাইকেল হ্যাম্পটন

12
@ মিশেল হ্যাম্পটন - এটি আমি এবং তিনি। আমিও বিকাশকারী। আপনি কি পরামর্শ দিচ্ছেন?
ক্রিস বি বেহরেন্স 21

10
প্রতিটি ভূমিকার জন্য পৃথক ব্যবহারকারীর অ্যাকাউন্টগুলি (ডি বনাম অপ্স / ডিবিএ)। এবং সতর্কতা একটি প্রাচুর্য।
মাইকেল হ্যাম্পটন

2
আমি দৃ strongly়ভাবে পরামর্শ দেব যে আপনার আলাদা পরিবেশে আপনার উত্পাদন পরিবেশ আছে on অন্যথায় মঞ্চায়ন এবং উত্পাদন সম্পদগুলি ভাগ করতে হবে - ডিস্ক, সিপিইউ ইত্যাদি - এবং যদি মঞ্চটি কোনও সংস্থানকে একচেটিয়াকরণ করে তবে আপনার উত্পাদন পরিবেশ ক্ষতিগ্রস্থ হতে পারে।
থোরবজর্ন রাভন অ্যান্ডারসন

1
এই ডাটাবেসগুলিতে কেবল পৃথক ব্যবহারকারী / পাসওয়ার্ড রয়েছে।
নিউট্রিনাস

উত্তর:


32

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

  • আপনি সঠিক সার্ভারে পুনরুদ্ধার করছেন তা যাচাই করুন (যেমন কোনও দেব -> প্রোড পুনরুদ্ধার করা হয়নি)
  • যাচাই করুন যে এটি ডাটাবেসের সঠিক "প্রকার" (আপনার ক্ষেত্রে, "মঞ্চায়ন" এবং "উত্পাদন")
  • এমএসডিবি-তে ব্যাকআপ টেবিলগুলি দেখে স্বয়ংক্রিয়ভাবে কোন ব্যাকআপটি পুনরুদ্ধার করবেন তা নির্ধারণ করুন

ইত্যাদি। আপনি কেবল আপনার কল্পনা দ্বারা সীমাবদ্ধ।


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

11
এখন আপনি পোর্টাল নিয়ে ভাবছেন। :)
বেন থুল

4
উত্পাদনে প্রভাবিত স্বয়ংক্রিয় কাজের জন্য, আমি একটি ম্যানুয়াল পদক্ষেপে যুক্ত করতে চাই যা ব্যবহারকারীকে "উত্পাদন" শব্দটি টাইপ করে সম্ভাবনা হ্রাস করতে পারে যে তারা মনে করে যে তারা মঞ্চের সমতুল্য খুঁজছেন।
জো লি-ময়েত

2
ডিফল্টরূপে কারও প্রযোজনায় অ্যাক্সেস না করা উচিত বলে আমি ডাউনটিভোট করেছি। প্রোড পাসওয়ার্ড পুনরুদ্ধার করতে আপনার একটি বিশেষ প্রক্রিয়া থাকতে হবে। এটি অসুবিধে হলেও সত্যিই সর্বনিম্ন।
অলিভারস

1
@ বেনথুল প্রোড অ্যাক্সেসের জন্য একটি আলাদা অ্যাকাউন্ট যুক্ত করা এবং এটিকে আরও একধাপ অসুবিধাজনক করা এখনও আমার কাছে সঠিক সমাধান। ব্যবসায়ের জন্য ডিইভি 2 মিনিট বাঁচার দরকার নেই তবে ডিবি পুনরুদ্ধার করা যা কোনও প্রোড অ্যাকাউন্টে নিখুঁতভাবে স্থানান্তরিত হতে পারে।
অলিভারস

32

আমি এই সুরক্ষা- এই প্রশ্নে অনুমানের সাথে একমত নই, তবে আমি এও একমত নই যে অটোমেশনটি নিজেই দিনটি বাঁচাতে চলেছে। আমি সমস্যাটি দিয়ে শুরু করব:

আপনি দুর্ঘটনাক্রমে উত্পাদনের জন্য কিছু করতে সক্ষম হবেন না !

এর মধ্যে দুর্ঘটনাক্রমে স্বয়ংক্রিয় জিনিসগুলি করা অন্তর্ভুক্ত।

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

আপনার কর্মপ্রবাহ বাছাইয়ের মাধ্যমে আপনাকে শুরু করতে হবে।

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

  • ব্যাকআপ ব্যবহারকারীরা কেবল উত্পাদন থেকে পড়তে এবং আপনার ব্যাকআপ স্টোরে (যা যথাযথভাবে সুরক্ষিত হওয়া উচিত) লিখতে সক্ষম হওয়া উচিত।

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

    উত্পাদনে অ্যাক্সেস করা আপনার প্রতিদিনের কিছু করা উচিত নয়। বেশিরভাগ কাজ আপনার টেস্টিং প্ল্যাটফর্মে থাকা উচিত এবং সাবধানতার সাথে তদন্তের পরে উত্পাদনে কয়েক ঘণ্টার মোতায়েন করা উচিত। একটু অসুবিধা আপনাকে মেরে ফেলবে না।

অটোমেশন সমাধানের অংশ

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

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

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

সব মাপের দলের জন্য উপযুক্ত।

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


2
তদতিরিক্ত, একটি জিনিস আমি করতে চাই প্রতি ব্যবহারকারী হিসাবে দুটি নামের অ্যাকাউন্ট ব্যবহার করা। একটি হ'ল সাধারণ ব্যবহারকারীর লগইন, অপারেশন, প্রতিদিনের কাজ ইত্যাদি while এইভাবে, ব্যবহারকারীকে দেবের বিপরীতে প্রোডগুলিতে চাপ দেওয়ার জন্য একটি সক্রিয় সিদ্ধান্ত নিতে হবে। এটি উপরে বর্ণিত বুলেট 3 এর মতো, তবে মানটি প্রদর্শনের জন্য উল্লেখযোগ্য অতিরিক্ত অবকাঠামো বা ব্যয় প্রয়োজন হয় না।
ব্যবহারকারী 24313

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

আমি সেই একই যুগের-পালা দ্বৈত-কী সঙ্কোচনগুলির মধ্যে একটি কোথায় পাব এবং এটি কি ইউএসবি সহ আসে?
লিলিয়েনথাল

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

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

12

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

আপনার মাইলেজটি পৃথক হতে পারে ... এবং আমার সম্ভবত এটি বলার দরকার নেই যে এটি নিজের পক্ষে খুব সহজেই বুলেটপ্রুফ রয়েছে। :)


2
আমি টার্মিনাল / ডিবি সংযোগে প্রোডাকশন সার্ভারের সাথে একটি বড় লাল পটভূমির রঙ ব্যবহার করি, পাশাপাশি পিসিগুলিতে অ্যাডমিন-একাউন্টগুলির জন্য উজ্জ্বল লাল ওয়ালপেপার ...
ফ্যালকো

হ্যাঁ, আমি ভাবছিলাম। প্রোডাকশন ফায়ার ইঞ্জিনকে লাল করুন ...
ক্রিস বি বেরেনস

রঙিন কোডিং সহায়তা করে। ঠিক যেমন একটি আইডিই।
থোরবজর্ন রাভন অ্যান্ডারসন

1

বিকাশকারীদের উত্পাদন ডাটাবেসের পাসওয়ার্ড জানতে হবে না। প্রোড পাসওয়ার্ডটি এলোমেলো এবং স্মরণীয় না হওয়া উচিত - কীবোর্ড ম্যাসিংয়ের ফলাফলের মতো ( Z^kC83N*(#$Hx)। তোমার দেব পাসওয়ার্ড হতে পারে $YourDog'sNameবা correct horse battery stapleবা যাই হোক না কেন।

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

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


আমি এটির সাথে পুরোপুরি একমত হতে পারি না, কারণ কোনও বাস্তবসম্মত বড় পরিবেশে নিয়মিত এমন নজির রয়েছে যেখানে বিকাশকারী / প্রশাসকদের উত্পাদন ডেটাবেস অ্যাক্সেস করতে হবে to একটি ত্রুটিহীন সিস্টেম এই ঘটতে কখনও উচিত সঙ্গে একটি নিখুঁত বিশ্বের অবশ্যই, কিন্তু অধিকাংশ সিস্টেমে আমি জানি তুমি হাত ধরে কিছু উৎপাদন ক্রিটিকাল ডেটা ঠিক করতে ... তাই আমি অলি সাথে আছি উৎপাদন লগইন অসুবিধাজনক হওয়া উচিত, কিন্তু সম্ভবপর মধ্যে
Falco

1
@ ফ্যালকো ঠিক তেমনটাই আমি প্রস্তাব দিচ্ছি। অসুবিধাজনক তবে সম্ভাব্য।
200_সাক্সেস

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

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

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

0

সংক্ষিপ্ত উত্তরটি হল আরবিএসি - ভূমিকা ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ।

সমস্ত পরিবেশের জন্য আপনার অনুমতিগুলি পৃথক হওয়া দরকার - এবং ইউএসি এর মতো জিনিসগুলির মতো বিরক্তিকর হিসাবে আপনার এগুলি প্রয়োজন: বিশেষত প্রড পরিবেশের জন্য for

নেই কখনও কতো ছোট সংগঠন / দল নির্বিশেষে - একটি কারণ devs উৎ থেকে সরাসরি প্রবেশাধিকার আছে জন্য। আপনার "দেব" "স্টেজ" এবং "প্রোড" টুপিও পরতে পারে তবে বিভিন্ন পরিবেশে আঘাত হানার জন্য তার আলাদা আলাদা শংসাপত্র এবং প্রক্রিয়া থাকা দরকার।

এটা কি বিরক্তিকর? একেবারে। কিন্তু এটি কি আপনার পরিবেশকে উদ্বুদ্ধ করা [সহায়তা] করে? একেবারে।


0

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

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


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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.