প্রাইভেট কীটি কোথায় সংরক্ষণ করবেন?


22

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

তবে, আমি যদি কিছু ক্লিয়ারটেক্সট এনক্রিপ্ট করি তবে আমি কীটি সংরক্ষণ করব? সফ্টওয়্যারটিতে যে কোনও কিছুতে অ্যাক্সেস রয়েছে, নির্ধারিত আক্রমণকারীর অ্যাক্সেস থাকতে পারে, তা কোন স্তরের অবরুদ্ধতা নয়:

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

ক্রিপ্টোগ্রাফি কেবল তার চেইনের দুর্বলতম লিঙ্কের মতোই শক্তিশালী এবং এটি বেশ আলগা মনে হচ্ছে! ধরে নিচ্ছেন যে এটি কাজের জন্য সঠিক সরঞ্জাম (আমাকে রসবোধ করুন), তবে কীভাবে এইরকম তথ্য দৃust়তার সাথে সুরক্ষিত করা যায়?


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

আমার কাছে তবে এটি এখনও অপর্যাপ্ত বলে মনে হচ্ছে: আমি চাই না যে কেউ যেখানে থাকুক না সে আশেপাশে কোথাও ঝাঁপিয়ে পড়ে!


6
আপনি খুঁজে পেতে পারেন Security.SE এ বিভিন্ন পোস্ট সুদের যাবে। আমি লক্ষ করব যে কিছু ফ্রেমওয়ার্ক এবং ভাষাগুলি এর জন্য বিশেষত সহায়তা সরবরাহ করে (উদাহরণস্বরূপ, .net এ এনক্রিপ্ট করা কনফিগারেশন বিভাগ)।
ব্রায়ান

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

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

2
আমনের উত্তর কোনও ব্যবহারকারীর মধ্যেই সীমাবদ্ধ নয় তবে কোনও ক্লায়েন্ট। ডিএক্সএম এমন একটি বক্তব্যও উত্থাপন করেছে যে আপনি নিজের সিস্টেমকে এমন কারও হাত থেকে রক্ষা করতে পারবেন না যে এটির সাথে छेड़छाड़ করতে চায় এবং তাদের পক্ষে এটি করা শক্ত করার জন্য আপনার শক্তি ব্যয় করা উচিত নয়। পরিবর্তে পণ্যটির উপর শক্তি ব্যয় করুন যাতে তাদের এটি করার কোনও আগ্রহ নেই
কেভিন

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

উত্তর:


25

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

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

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

প্রশ্নটি পরিষ্কার তাই আমি প্রথমে আপনার প্রতিটি পয়েন্টকে সম্বোধন করার চেষ্টা করব:

বলুন কী কীটি ফাইল সিস্টেমের সুরক্ষা মডেল দ্বারা সুরক্ষিত; তবে (দূষিত) সুপারইউসার বা প্ল্যাটফর্মগুলির সম্পর্কে কী যা এরূপ বিশ্বস্ততা দেয় না?

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

বা কীটি সফ্টওয়্যার বাইনারিগুলিতে হার্ডকোড করা আছে তবে এটি সর্বদা বিশৃঙ্খল হতে পারে এবং ওপেন সোর্স সফ্টওয়্যার বা ব্যাখ্যাযুক্ত কোড সম্পর্কে কী বলা যায়?

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

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

হ্যাঁ, মূলতঃ তবে অ্যালগরিদম ব্যক্তিগত কী তৈরির জন্য ব্যক্তিগত কী তথ্য হয়ে যায়। সুতরাং, এটি এখন সুরক্ষিত করা প্রয়োজন।

সুতরাং, আমি মনে করি আপনি কোনও সুরক্ষা নীতি, কী পরিচালনা সহ একটি মূল সমস্যা চিহ্নিত করেছেন । একটি নিরাপদে ব্যবস্থা সরবরাহের জন্য মূল কী পরিচালনার নীতি রাখা কেন্দ্রীয়। এবং এটি একটি বিস্তৃত বিষয়

সুতরাং, প্রশ্নটি হল, আপনার সিস্টেমটি (এবং, সুতরাং ব্যক্তিগত কী) কতটা সুরক্ষিত হওয়া দরকার? আপনার সিস্টেমে কত উচ্চ, বারটি বাড়াতে হবে?

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

অনেক এইচএসএম বৈশিষ্ট্যগুলি রক্ষণাবেক্ষণ এবং প্রশাসক থেকে কী কার্ডগুলি ব্যবহার করে। কী কার্ডগুলির একটি কোরাম (9 এর মধ্যে 5 বলুন) কোনও কী পরিবর্তন করার জন্য শারীরিকভাবে সার্ভারে রাখতে হবে। সুতরাং, যদি সুপার ব্যবহারকারীদের একটি কোরামের সংগৃহীত হয় তবে এটি লঙ্ঘনের অনুমতি দিয়ে বারটিকে বেশ উচ্চতর করে তোলে।

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

আমি জানি এটি কেবল প্রশ্নের উত্তর দেওয়ার কিছুটা পথ রয়েছে তবে আমি আশা করি এটি সাহায্য করবে।


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

2

আপনি যা চান তা করা যায় না।

বলুন কী কীটি ফাইল সিস্টেমের সুরক্ষা মডেল দ্বারা সুরক্ষিত; তবে (দূষিত) সুপারইউসার বা প্ল্যাটফর্মগুলির সম্পর্কে কী যা এরূপ বিশ্বস্ততা দেয় না?

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

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


2

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

প্রথম দর্শনটি "ক্লায়েন্টকে বিশ্বাস করবেন না" এবং ঘনিষ্ঠভাবে সম্পর্কিত "যদি আপনি সত্যই কোনও গোপন রাখতে চান তবে কাউকে বলবেন না!"

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

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

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

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

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

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

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


টিএলডিআর: ব্যবহারকারীর কাছ থেকে গোপনীয়তা রাখবেন না, ব্যবহারকারীর সাথে গোপনীয়তা রাখুন।


1

আমি বর্তমানে ব্যবহার করি এমন একটি সিস্টেম এইভাবে কাজ করে।

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

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

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

সুতরাং আপনাকে ক্লায়েন্ট অ্যাক্সেসযোগ্য মেশিন থেকে আপনার সুরক্ষিত পরিষেবাটি আলাদা করতে হবে। সুরক্ষিত পরিষেবাটি কেবল নেটওয়ার্কের মাধ্যমে অ্যাক্সেসযোগ্য কোনও মেশিনে সরান। আপনার ক্লায়েন্টদের ভার্চুয়াল মেশিনগুলিতে রাখুন যা আপনার সুরক্ষিত পরিষেবা চালিত সেখানে অন্যান্য শারীরিক মেশিনে পৌঁছাতে বাধা দেয়।

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


-1

মনে মনে, এটিকে পুরোপুরি নিরাপদ রাখার একমাত্র উপায় হ'ল আনলক করার জন্য পাসফ্রেজের সাহায্যে কী / পাসওয়ার্ড এনক্রিপ্ট করা। এই গোপনীয়তা প্রতিটি ব্যবহার বা ব্যবহারের জন্য পাসফ্রেজ অবশ্যই দিতে হবে .. খুব বেশি কার্যকর নয় Not

আর একটি উপায় হতে পারে সুরক্ষা সিস্টেমটি এটি ডেটাবেস অ্যাকাউন্ট হিসাবে স্ব। খুব স্কেলযোগ্য নয় ...

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

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