Encryption ও Secrets: key rotation ও least privilege
Encryption, Secrets, and Least Privilege
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Hashing, encryption ও transport protection আলাদা করা
- Laravel secret configuration সুরক্ষিত রাখা
- Key rotation এবং least privilege বোঝা
সমস্যা দিয়ে শুরু
Database backup চুরি হলে customer note পড়া যাচ্ছে। আবার password encrypt করে রাখা হয়েছে, তাই application key চুরি হলেই সব password উদ্ধার সম্ভব। Team encryption শব্দটি ব্যবহার করেছে, কিন্তু কোন data পুনরুদ্ধারযোগ্য থাকা দরকার আর কোনটি শুধু verify করতে হবে তা আলাদা করেনি। Secret ও key একই repository-তে থাকলে encryption-এর উদ্দেশ্যও অনেকটা নষ্ট হয়।
সহজ করে বুঝি
Encryption key দিয়ে plaintext পুনরুদ্ধারযোগ্য করে; hashing একমুখী verification-এর জন্য। Password adaptive password hash দিয়ে রাখুন, reversible encryption নয়। TLS transit সুরক্ষা দেয়; storage encryption at rest আলাদা স্তর। Laravel Crypt authenticated encryption দেয়, আর Hash password hashing interface দেয়। Key যার হাতে, তার ক্ষমতা ও operational access সীমিত করুন। Secret log, URL বা image layer-এ যেন না যায়।
পরিচিত একটি উপমা
তালা দেওয়া বাক্স encryption: চাবি দিয়ে লেখা ফেরত পড়া যায়। Password hash হলো পরিচয়ের এমন পরীক্ষা যেখানে আসল password ফেরত বের করার দরকার নেই। বাক্স ও চাবি একই খোলা drawer-এ রাখলে তালার সুবিধা কমে যায়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR N[Sensitive note] --> E[Application encryption] K[Protected application key] --> E E --> D[(Ciphertext database)] P[Password] --> H[Password hash] H --> U[(User credential record)]
Note encrypt হয়ে database-এ ciphertext যায়, key আলাদা protected configuration থেকে আসে। Password আলাদা hash path-এ যায়; login-এ hash verify হয়। Database dump-এ ciphertext থাকলেও application key compromise হলে note রক্ষা পাবে না। Backup, worker ও rotated key access-এর পরিকল্পনাও একই data lifecycle-এর অংশ।
PHP ও Laravel-এ প্রয়োগ
Service-method fragment। $validatedNote input validated এবং actor authorized; CustomerNote model ciphertext column যথেষ্ট বড়। APP_KEY runtime secret এবং backup key management configured ধরে নেওয়া হয়েছে। Password example registration pipeline-এর অংশ; encrypted value response বা log-এ প্রকাশ করবেন না।
use Illuminate\Support\Facades\Crypt;
use Illuminate\Support\Facades\Hash;
$ciphertext = Crypt::encryptString($validatedNote);
$plaintext = Crypt::decryptString($ciphertext);
$passwordHash = Hash::make($validatedPassword);
$isValid = Hash::check($candidatePassword, $passwordHash);সুবিধা, সীমাবদ্ধতা ও trade-off
Application encryption database-only exposure-এর ক্ষতি কমাতে পারে, কিন্তু searchable index, key rotation এবং recovery জটিল হয়। Plaintext দরকার না হলে data না রাখাই ভালো। Every field encrypt করলে query ও sorting কঠিন হতে পারে। Least privilege application DB account-কে schema admin না করে প্রয়োজনীয় action-এ সীমিত রাখে; encryption-এর পাশাপাশি access control জরুরি।
সাধারণ ভুল
- Password reversible encryption-এ রাখা।
- APP_KEY বা API token commit করা।
- Key বদলে পুরোনো ciphertext পড়া যাবে ধরে নেওয়া।
আরও একটু গভীরে
Rotation plan-এ নতুন write key, পুরোনো decrypt key, re-encryption progress ও rollback window নির্ধারণ করুন। Laravel-এর documented previous-key support নির্দিষ্ট configuration-এ সহায়ক; তা সব external secret ঘোরায় না। Key হারালে encrypted backup-ও unusable হতে পারে। Key access audit এবং restore rehearsal করুন। Central secret manager নিলে তার outage ও permission boundary-ও design করতে হবে।
মনে রাখুন
Password hash করুন, recoverable sensitive data encrypt করুন, আর key-এর access ও recovery আলাদাভাবে সুরক্ষিত রাখুন।
নিজে চেষ্টা করুন
Customer note-এর data inventory বানান। কোন field না রাখলেও চলে, কোনটি hash এবং কোনটি encryption চাই লিখুন। Staging-এ key rotation rehearsal করে পুরোনো data decrypt এবং backup restore behavior যাচাই করুন।
নিজের বোঝা যাচাই করুন
1. Password encrypt করব?
সাধারণ login password adaptive hash দিয়ে রাখুন। Verification-এর জন্য original password ফেরত আনার প্রয়োজন নেই।
2. TLS থাকলে disk encryption দরকার নেই?
দুটি আলাদা threat সামলায়। Transit এবং stored data exposure পৃথকভাবে মূল্যায়ন করুন।
3. APP_KEY হারালে কী?
তার উপর নির্ভরশীল ciphertext decrypt নাও হতে পারে। Protected backup ও tested rotation/recovery plan দরকার।
4. Encryption কি authorization বদলে দেয়?
না। Authorized app plaintext পড়তে পারে, তাই resource permission ও least privilege বজায় রাখতে হবে।
5. সব secret এক key-তে?
Application encryption key, provider API token ও signing keys-এর lifecycle ভিন্ন হতে পারে। Inventory ও rotation owner আলাদা লিখুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।