মাইএসকিউএল-এ এনক্রিপশন: কীস্টোর

কোর্সের জন্য একটি নতুন তালিকাভুক্তি শুরু হওয়ার প্রত্যাশায় "তথ্যশালা" আমরা আপনার জন্য একটি দরকারী নিবন্ধের অনুবাদ প্রস্তুত করেছি।

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

মাইএসকিউএল কীরিং

কীরিং হল এমন প্লাগইন যা সার্ভারকে স্থানীয় ফাইল (keyring_file) বা রিমোট সার্ভারে (যেমন HashiCorp Vault) কী অনুসন্ধান করতে, তৈরি করতে এবং মুছে ফেলার অনুমতি দেয়। তাদের পুনরুদ্ধারের গতি বাড়ানোর জন্য কীগুলি সর্বদা স্থানীয়ভাবে ক্যাশ করা হয়।

প্লাগইন দুটি বিভাগে বিভক্ত করা যেতে পারে:

• স্থানীয় স্টোরেজ। উদাহরণস্বরূপ, একটি স্থানীয় ফাইল (আমরা এটিকে একটি ফাইল-ভিত্তিক কীরিং বলি)।
• দূরবর্তী স্টোরেজ। উদাহরণস্বরূপ, ভল্ট সার্ভার (আমরা এটিকে সার্ভার-ভিত্তিক কীরিং বলি)।

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

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

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

মূল তথ্য নিম্নলিখিত রয়েছে:

• কী আইডি — কী শনাক্তকারী, উদাহরণস্বরূপ:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• চাবির ধরন — ব্যবহৃত এনক্রিপশন অ্যালগরিদমের উপর ভিত্তি করে কী প্রকার, সম্ভাব্য মান: “AES”, “RSA” বা “DSA”।
• কী দৈর্ঘ্য — বাইটে কী দৈর্ঘ্য, AES: 16, 24 বা 32, RSA 128, 256, 512 এবং DSA 128, 256 বা 384।
• ব্যবহারকারী - চাবির মালিক। যদি কীটি সিস্টেম হয়, উদাহরণস্বরূপ, মাস্টার কী, তাহলে এই ক্ষেত্রটি খালি। যদি keyring_udf ব্যবহার করে একটি কী তৈরি করা হয়, তাহলে এই ক্ষেত্রটি কীটির মালিককে শনাক্ত করে।
• চাবি নিজেই

কীটি জোড়া দ্বারা স্বতন্ত্রভাবে চিহ্নিত করা হয়: key_id, ব্যবহারকারী।

কী সংরক্ষণ এবং মুছে ফেলার মধ্যেও পার্থক্য রয়েছে।

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

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

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

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

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

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

আমি কি বলতে চাইছি? ক্লাস্টারের প্রতিটি সার্ভারের (উদাহরণস্বরূপ, পারকোনা সার্ভার) ভল্ট সার্ভারে একটি পৃথক অবস্থান থাকতে হবে যেখানে পারকোনা সার্ভারকে অবশ্যই তার কীগুলি সংরক্ষণ করতে হবে। স্টোরেজে সংরক্ষিত প্রতিটি মাস্টার কী এর শনাক্তকারীর মধ্যে পারকোনা সার্ভারের GUID ধারণ করে। এটা কেন গুরুত্বপূর্ণ? কল্পনা করুন যে আপনার শুধুমাত্র একটি ভল্ট সার্ভার আছে এবং ক্লাস্টারের সমস্ত পারকোনা সার্ভার সেই একক ভল্ট সার্ভার ব্যবহার করে। সমস্যা সুস্পষ্ট বলে মনে হচ্ছে। যদি সমস্ত পারকোনা সার্ভার অনন্য শনাক্তকারী ছাড়া একটি মাস্টার কী ব্যবহার করে, যেমন id = 1, id = 2, ইত্যাদি, তাহলে ক্লাস্টারের সমস্ত সার্ভার একই মাস্টার কী ব্যবহার করবে। GUID যা প্রদান করে তা হল সার্ভারের মধ্যে পার্থক্য। যদি একটি অনন্য GUID ইতিমধ্যেই বিদ্যমান থাকে তবে কেন সার্ভারের মধ্যে কী ভাগ করার বিষয়ে কথা বলবেন? আরেকটি প্লাগইন আছে - keyring_udf। এই প্লাগইনের মাধ্যমে, আপনার সার্ভার ব্যবহারকারী ভল্ট সার্ভারে তাদের কী সংরক্ষণ করতে পারে। সমস্যাটি ঘটে যখন একজন ব্যবহারকারী সার্ভার 1 এ একটি কী তৈরি করে, এবং তারপর সার্ভার 2 এ একই আইডি দিয়ে একটি কী তৈরি করার চেষ্টা করে, উদাহরণস্বরূপ:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

অপেক্ষা করুন। উভয় সার্ভার একই ভল্ট সার্ভার ব্যবহার করছে, keyring_key_store ফাংশন সার্ভার 2 এ ব্যর্থ হওয়া উচিত নয়? মজার বিষয় হল, আপনি যদি একটি সার্ভারে একই কাজ করার চেষ্টা করেন, আপনি একটি ত্রুটি পাবেন:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

এটা ঠিক, ROB_1 ইতিমধ্যেই বিদ্যমান।

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

প্রথম ক্ষেত্রে পরিস্থিতি ভিন্ন। সার্ভার 1 এবং সার্ভার 2 এর আলাদা ক্যাশে রয়েছে। সার্ভার 1 এবং ভল্ট সার্ভারের কী ক্যাশে ROB_1 যোগ করার পরে, সার্ভার 2-এর কী ক্যাশে সিঙ্কের বাইরে। সার্ভার2-এর ক্যাশে কোনো ROB_1 কী নেই। এইভাবে, ROB_1 কীটি keyring_key_store এবং Vault সার্ভারে লেখা হয়, যা প্রকৃতপক্ষে পূর্ববর্তী মানটিকে ওভাররাইট করে (!)। এখন ভল্ট সার্ভারে ROB_1 কী হল 543210987654321৷ মজার বিষয় হল, ভল্ট সার্ভার এই ধরনের ক্রিয়াগুলিকে ব্লক করে না এবং সহজেই পুরানো মানটিকে ওভাররাইট করে৷

এখন আমরা দেখতে পাচ্ছি কেন ভল্টে সার্ভার পার্টিশন করা গুরুত্বপূর্ণ হতে পারে - যখন আপনি keyring_udf ব্যবহার করছেন এবং ভল্টে কী সংরক্ষণ করতে চান। কিভাবে একটি ভল্ট সার্ভারে এই বিচ্ছেদ অর্জন?

ভল্টে ভাগ করার দুটি উপায় রয়েছে। আপনি প্রতিটি সার্ভারের জন্য বিভিন্ন মাউন্ট পয়েন্ট তৈরি করতে পারেন, বা একই মাউন্ট পয়েন্টের মধ্যে বিভিন্ন পাথ ব্যবহার করতে পারেন। এটি উদাহরণ দিয়ে সবচেয়ে ভালভাবে চিত্রিত করা হয়েছে। সুতরাং আসুন প্রথমে পৃথক মাউন্ট পয়েন্টগুলি দেখি:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

এখানে আপনি দেখতে পাচ্ছেন যে সার্ভার 1 এবং সার্ভার 2 বিভিন্ন মাউন্ট পয়েন্ট ব্যবহার করছে। পাথগুলিকে বিভক্ত করার সময়, কনফিগারেশনটি এইরকম দেখাবে:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

এই ক্ষেত্রে, উভয় সার্ভার একই মাউন্ট পয়েন্ট "মাউন্ট_পয়েন্ট" ব্যবহার করে, কিন্তু ভিন্ন পাথ। যখন আপনি এই পথটি ব্যবহার করে সার্ভার 1-এ প্রথম গোপনীয়তা তৈরি করেন, তখন ভল্ট সার্ভার স্বয়ংক্রিয়ভাবে একটি "সার্ভার1" ডিরেক্টরি তৈরি করে। সার্ভার 2 এর জন্য সবকিছু একই রকম। আপনি mount_point/server1 বা mount_point/server2-এ শেষ গোপন মুছে দিলে, ভল্ট সার্ভার সেই ডিরেক্টরিগুলিও মুছে দেয়। যদি আপনি পাথ বিচ্ছেদ ব্যবহার করেন, আপনাকে অবশ্যই শুধুমাত্র একটি মাউন্ট পয়েন্ট তৈরি করতে হবে এবং কনফিগারেশন ফাইলগুলি পরিবর্তন করতে হবে যাতে সার্ভারগুলি পৃথক পাথ ব্যবহার করে। একটি মাউন্ট পয়েন্ট একটি HTTP অনুরোধ ব্যবহার করে তৈরি করা যেতে পারে। CURL ব্যবহার করে এটি এভাবে করা যেতে পারে:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

সমস্ত ক্ষেত্র (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) কনফিগারেশন ফাইলের প্যারামিটারের সাথে মিলে যায়৷ অবশ্যই, আপনি একই করতে ভল্ট ইউটিলিটি ব্যবহার করতে পারেন। কিন্তু একটি মাউন্ট পয়েন্ট তৈরি স্বয়ংক্রিয় করা সহজ। আমি আশা করি আপনি এই তথ্যটি দরকারী বলে মনে করেন এবং আমরা এই সিরিজের পরবর্তী নিবন্ধগুলিতে আপনাকে দেখতে পাব।

আরও পড়ুন:

• সিসবেঞ্চ এবং এলোমেলো ভেরিয়েবলের বিতরণ

উত্স: www.habr.com