আমার কি ডাটাবেসে ডেটা এনক্রিপ্ট করা উচিত?

16

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

সমস্যাটি হ'ল এটি সংবেদনশীল ডেটা, রোগীর ইতিহাস এবং এই জাতীয়।

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

আমি স্বাস্থ্য সংক্রান্ত সমস্যা (পর্তুগাল) সম্পর্কিত ডেটা সুরক্ষা সম্পর্কিত আইনগুলি পড়েছি, তবে এ সম্পর্কে খুব সুনির্দিষ্ট নয় (আমি তাদের সম্পর্কে এই প্রশ্নটি নিয়েছি, আমি তাদের প্রতিক্রিয়ার জন্য অপেক্ষা করছি)।

আমি নীচের লিঙ্কটি পড়েছি , তবে আমার প্রশ্নটি আলাদা, আমার কি ডাটাবেসে ডেটা এনক্রিপ্ট করা উচিত, না।

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

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

php mysql encryption

— Tio
সূত্র

1

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

— এরিক পুনরায়

4

আপনি কি পুরো ডাটাবেসটিকে একটি এনক্রিপ্ট করা ভলিউমে রাখতে এবং একটি দিন কল করতে পারেন? অবশ্যই পড়া / লেখাগুলি ধীর হবে, তবে আপনি আরডিএমএসের সমস্ত সুবিধা রাখেন (বা আপনি যা ব্যবহার করছেন), যখন ডিস্কের ডেটা এনক্রিপ্ট করা আছে

— DXM

2

এর অর্থ হ'ল আপনি কি মাইএসকিএল ওয়ার্কবেঞ্চে ডেটা দেখতে সক্ষম হবেন? ডিবাগিংয়ের জন্য সেরা।

— মনোজ আর

4

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

— 12 '

1

ব্রিটেনের একটি হাসপাতালে £ 300,000 এর বেশি জরিমানা করা হয়েছিল কারণ ডিস্ক ড্রাইভগুলি এনক্রিপ্ট না করা ডেটাবেসগুলিকে ভুল পথে চালিত করে। স্বাস্থ্য তথ্য অত্যন্ত সংবেদনশীল।

— মার্কজে

9

আমি ব্যক্তিগতভাবে এ সংক্রান্ত আইনগুলি পরীক্ষা করব। যদি ডেটা এনক্রিপ্ট করা দরকার হয়, তবে এটি এনক্রিপ্ট করা দরকার।

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

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

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

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

— এম আফিফি
সূত্র

1

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

— কেভিন

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

— জালাবোজা

13

হ্যাঁ, আপনার ডাটাবেসটি এনক্রিপ্ট করা উচিত।

সঞ্চিত ডেটার জন্য বেসিক এনক্রিপশন ("বিশ্রামে থাকা ডেটা") একটি সাধারণভাবে গৃহীত সুরক্ষা নীতি, এবং সম্ভবত যদি আপনার দেশে ব্যক্তিগত বা স্বাস্থ্য সম্পর্কিত তথ্য সুরক্ষিত করে এমন আইন থাকে তবে এটি আইন দ্বারা বাধ্যতামূলক হয়।

আমরা এসকিউএল সার্ভার ২০০৮ ব্যবহার করছি, সুতরাং আমরা মাইক্রোসফ্টের টিডিই ব্যবহার করি; মাইএসকিউএল এর জন্য কিছু তৃতীয় পক্ষের সমাধান থাকতে পারে বা সম্ভবত একটি সাধারণ ভলিউম এনক্রিপশন পদ্ধতির (যেমন ট্রুক্রিপ্ট) কাজ করবে (যদিও আমি এমন কিছু চাই যা ডেটাবেস ব্যবহারের জন্য প্রত্যয়িত হয়েছে)।

যদি সঠিকভাবে করা হয় তবে পারফরম্যান্স হিটটি ছোট হওয়া উচিত।

যাইহোক, আপনি উল্লিখিত লিঙ্কটি (সংবেদনশীল তথ্যের পৃথকীকরণ সম্পর্কিত) এমন একটি বিষয় যা আপনার বুনিয়াদি ডাটাবেস এনক্রিপশনের শীর্ষে বিবেচনা করা উচিত।

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

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

— jdigital
সূত্র

2

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

— মনোজ আর

1

পারফরম্যান্স হিট ছোট হওয়া উচিত? ডেটা অনুসন্ধান করা কম হবে। ইনডেক্সিংয়ের সম্পূর্ণ ধারণাটি ডেটা এনক্রিপ্ট করা অবস্থায় কাজ করে না। এটির জন্য একটি পূর্ণ-টেবিল স্ক্যান প্রয়োজন।

— মাইকে

@ মাইক উপরের পদ্ধতির পরিমাণটি এনক্রিপ্ট হবে এবং

— সূচি

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

— কেভিন

8

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

এখন, এই প্রসঙ্গে আপনি কয়েকটি বিষয় চিন্তা করতে পারেন:

আক্রমণকারীরা আপনার ডেটাতে শারীরিক অ্যাক্সেস অর্জন করছে (উদাহরণস্বরূপ, ডেটাসেন্টারে প্রবেশ করানো, ব্যাকআপ টেপ চুরি করা ইত্যাদি)
আক্রমণকারীরা আপনার কাঁচা ডাটাবেসে পড়ার অ্যাক্সেস অর্জন করছে
আক্রমণকারীরা আপনার অ্যাপ্লিকেশনটির সাথে আপস করছে, যেমন এসকিউএল ইঞ্জেকশন, বাফারকে ছাড়িয়ে আনা ইত্যাদি etc.

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

দ্বিতীয় দৃশ্যের জন্য, ডাটাবেস ডেটা এনক্রিপ্ট করা সাহায্য করে, তবে কেবল যদি আপনি প্রয়োজনীয় কী বা পাসফ্রেজগুলি কোথাও না সঞ্চয় করেন।

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

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

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

— tdammers
সূত্র

2

+1: কোনও হুমকির মডেল ছাড়াই আপনি সম্ভবত সামনের দরজাটি লক করছেন তবে পিছনের দরজাটি প্রশস্ত রেখে যাচ্ছেন।

— কেভিন

8

ক্লায়েন্ট কী জিজ্ঞাসা করছে এবং আইন যা-ই হোক না কেন এক মুহুর্তের জন্য উপেক্ষা করা ...

না, আপনার সম্ভবত ডেটা এনক্রিপ্ট করা উচিত নয়। আপনি যদি এটি করেন তবে আপনি সহজেই এটি অনুসন্ধান করতে পারবেন না। উদাহরণস্বরূপ, like 'Smith%'প্রতিটি নামের এন্ট্রি এনক্রিপ্ট করা থাকলে আপনি শেষ নামটি কীভাবে অনুসন্ধান করবেন ? ক্যান না পারলে সময়ের সাথে আপনি কীভাবে একজন রোগীর রক্তচাপ গ্রাফ করবেন select .... from.... where patient_id = N?

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

ব্যাখ্যা: এই অভিমানী কি ওপি সম্পর্কে আসলে ডেটা এনক্রিপ্ট করা হয় জিজ্ঞাসা ছিল মধ্যে ডাটাবেস। ডাটাবেস ফাইল ফাইল থাকে না।

— GrandmasterB
সূত্র

সম্পূর্ণরূপে সম্মত, তবুও

— আইনশাসনগুলি

1

আচ্ছা আপনি AES_DESCRYPT('') LIKE 'Smith%'অবিশ্বাস্যভাবে ধীর হতে পারে । অথবা আপনি তীব্র হয়ে উঠতে এবং লবণযুক্ত হ্যাশগুলির সাথে একটি উল্টানো সূচক তৈরি করতে পারেন

— ফুচো

1

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

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

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

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

— Reactgular
সূত্র

1

হ্যাঁ, আপনার ডাটাবেসটি এনক্রিপ্ট করা উচিত।

যেহেতু এটি ব্যক্তিগত এবং সংবেদনশীল তথ্য, আমি অবশ্যই এটি বিশ্বাস করি।

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

— dagnelies
সূত্র

লোকেরা খুব প্রায়ই তাদের পাসওয়ার্ড ভুলে যায় ... তবে কী?

— কৌতূহলী

-1

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

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

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

— sschrass
সূত্র

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

— জে এলস্টন

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

— sschras

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

— জে এলস্টন