গোপনীয়তা উত্স নিয়ন্ত্রণের বাইরে রাখা - আমরা কি সমস্যাটি সরিয়ে দিচ্ছি?


10

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

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

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

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

উত্তর:


12

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

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


4

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

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

এখন আপনার কিছু যুক্তি সম্বোধন করতে:

সাধারণভাবে, আমরা কি কেবল সমস্যাটি চালাচ্ছি না?

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

এর ভাল উদাহরণ হতে পারে কোনও সার্ভারে একটি এনক্রিপ্ট করা ফাইল সঞ্চয় করা st আমার কাছে একটি গোপন ডিক্রিপশন কী রয়েছে যা আমাকে অবশ্যই অন্য একটি ফাইলে গোপন রাখতে হবে।

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

আবার, নিখুঁত সুরক্ষার মতো কোনও জিনিস নেই তবে একাধিক নিয়ন্ত্রণের লক্ষ্য নিশ্চিত করে যে একাধিক ব্যর্থতা প্রকাশের জন্য ঘটতে হবে।

আমার কাছে মনে হচ্ছে অ্যাজুরে কীভল্টের মতো পণ্যগুলি এর চেয়ে ভাল আর অর্থহীনভাবে আরও জটিল নয়,

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

আপনার গোপনীয়তা আলাদা আলাদা কনফিগার ফাইলে রাখা এবং এটি আপনার .gitignore বা সমমানের মধ্যে রয়েছে তা নিশ্চিত করার চেয়ে।

দুর্ঘটনাক্রমে কেউ এটিকে উত্স নিয়ন্ত্রণে পরীক্ষা না করা পর্যন্ত গোপনীয়তা চিরকালের জন্য উত্স নিয়ন্ত্রণের ইতিহাসে এম্বেড করা থাকে।

অবশ্যই, লোকেরা একে অপরকে সম্ভবত নিরাপদে ইমেল করবে ...

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

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

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

অনেক কিছুর মতো, সুরক্ষা হ'ল একটি বিষয় যা আপনাকে বিষয়গত মানদণ্ড, উপাত্তের প্রকৃতি, প্রকাশের পরিণতি, ঝুঁকি ক্ষুধা, বাজেট ইত্যাদির উপর ভিত্তি করে আঁকতে হয় ...


0

গিট রেপোতে গোপন ফাইলগুলিকে অ্যাসিমেট্রিক কী দিয়ে এনক্রিপ্ট করা রাখতে git secretপ্রকল্পের ( http://git-secret.io/ ) বিবেচনা করা উচিত । পাবলিক কীগুলি রেপোতেও রয়েছে, ব্যক্তিগত কী নেই।

এই পদ্ধতির বৈশিষ্ট্যগুলি হ'ল:

  • যখন নতুন ব্যবহারকারী / মেশিনকে সুরক্ষিত ফাইলগুলি ডিক্রিপ্ট করার প্রয়োজন হয় - তিনি তার পাবলিক জিপিজি (gnu প্রাইভেসি প্রাইভেট গার্ড ওরফে পিজিপি) কীটি প্রকাশ / প্রেরণ করেন। যে ব্যবহারকারী ইতিমধ্যে সুরক্ষিত ফাইলগুলি ডিক্রিপ্ট করতে পারবেন তারা নতুন অতিরিক্ত কী দিয়ে পুনরায় এনক্রিপ্ট করতে পারবেন - তার পরে নতুন ব্যবহারকারী তার ব্যক্তিগত কী দ্বারা সুরক্ষিত ফাইলগুলি ডিক্রিপ্ট করতে পারবেন।
  • স্পষ্টতই আপনাকে নিয়ন্ত্রণ করতে হবে যে গিট সংগ্রহস্থলটিতে প্রতিশ্রুতিবদ্ধ / চাপ দিতে পারে। অন্যথায় আক্রমণকারী তার নিজস্ব পাবলিক কীটি করতে পারে এবং কোনও অনুমোদিত ব্যক্তি এই নতুন আপোসড পাবলিক কী দিয়ে সুরক্ষিত ফাইলগুলি পুনরায় এনক্রিপ্ট না করা পর্যন্ত অপেক্ষা করতে পারে।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.