Secret আর KMS — envelope encryption, rotation আর secret manager

১ · Secret কী, আর সেটি কোন পথে বেরিয়ে যায়

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। ডেভেলপার তাড়াহুড়োয় database password কোডে লিখে দিলেন। কোড গেল Git-এ, Git থেকে Docker image-এ, image থেকে দশটি server-এ। এখন সেই একটি password কোথায় কোথায় আছে, কেউ বলতে পারে না।

Secret হলো এমন যেকোনো তথ্য, যা হাতে পেলেই কেউ আপনার পরিচয়ে কিছু করতে পারে। Database password, API key, access key, TLS private key, SSH key, webhook signing secret, OAuth client secret, সবই secret. চেনার সহজ পরীক্ষা হলো, “এটি প্রকাশ্যে ছাপা হলে কি আজই কিছু বদলাতে হবে?” উত্তর হ্যাঁ হলে সেটি secret.

Secret সাধারণত হ্যাকিং করে চুরি হয় না, ভুল জায়গায় পড়ে থাকে। পাঁচটি পথ বারবার দেখা যায়:

Git-এ secret ফাঁসের পুরো বিবরণ আছে Git নিরাপত্তা পর্বে। এখানে আমরা দেখব cloud-এ কীভাবে secret রাখা আর চালানো হয়।

২ · Encryption-এর তিন অবস্থা — রাখা, পথে আর ব্যবহারে

Secret রাখার আগে encryption কী পাহারা দেয়, তা বুঝে নিন। Plaintext হলো খোলা ডেটা, আর ciphertext হলো key ছাড়া অর্থহীন ডেটা। ডেটা তিন অবস্থায় থাকে, আর প্রতিটির পাহারা আলাদা। AES, HMAC আর public key-এর গণিত Cryptography-র ভিত্তি পর্বে আছে। এখানে শুধু মনে রাখুন, AES হলো symmetric encryption: একই key দিয়ে লক আর খোলা।

৩ · KMS — যে চাবি ঘর ছাড়ে না

ডেটা encrypt করলে নতুন প্রশ্ন আসে, key কোথায় রাখবেন? Key ডেটার পাশে রাখলে তালার পাশে চাবি ঝুলিয়ে রাখার মতো হয়। KMS (Key Management Service) এর উত্তর। এটি provider-এর চালানো একটি service, যা key রাখে আর আপনার হয়ে key ব্যবহার করে। মূল কথা হলো, key আপনার কাছে আসে না, আপনার অনুরোধ key-এর কাছে যায়।

KMS-এর চারটি অংশ জানলেই বাকিটা সহজ হয়:

• Key যা বের হয় না: সাধারণ KMS key-এর গোপন অংশ provider-এর সুরক্ষিত hardware-এর বাইরে খোলা অবস্থায় আসে না। আপনি পাঠান ডেটা, ফেরত পান ফল। Provider ও key-এর ধরনভেদে এর ব্যতিক্রম থাকতে পারে, যেমন নিজের আনা key material.
• Key policy: কে এই key ব্যবহার করবে আর কে পরিচালনা করবে, তার নিয়ম। AWS-এ প্রতিটি key-এর নিজের policy থাকে, আর সেটি অনুমতি না দিলে IAM policy একা যথেষ্ট নয়। Google Cloud আর Azure-এ একই কাজ হয় key-এর ওপর IAM বা role দিয়ে।
• Grant: AWS-এর শব্দ। একটি service বা role-কে নির্দিষ্ট কাজের সাময়িক অনুমতি, যা policy না বদলে দেওয়া আর ফেরত নেওয়া যায়। যেমন disk service-কে শুধু ওই volume-এর জন্য key ব্যবহারের অধিকার।
• Audit trail: প্রতিটি key ব্যবহার audit log-এ যায়: কে, কখন, কোন key, কোন কাজ, সফল কি না। Password একবার পড়লে কোনো চিহ্ন থাকে না, কিন্তু KMS-এর প্রতিটি decrypt-এর চিহ্ন থাকে।

কাজের ভাগ আলাদা রাখুন। যিনি key পরিচালনা করেন (rotation, মুছে ফেলা), তিনি ডেটা decrypt করবেন না। আর যে app decrypt করে, সে key মুছতে পারবে না। নিচের key policy অংশে app শুধু দুটি কাজ পায়:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AppUsesKeyOnly",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/shop-app" },
      "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:ViaService": "s3.ap-south-1.amazonaws.com" }
      }
    }
  ]
}

এখানে "Resource": "*" দেখে ঘাবড়াবেন না: key policy-তে এর মানে শুধু এই key. kms:ViaService বলছে, অনুরোধ আসতে হবে S3-র মাধ্যমে। সম্পূর্ণ policy-তে key পরিচালকের জন্য আলাদা statement-ও লাগে, নইলে key নিজেই অচল হয়ে যেতে পারে।

৪ · Envelope encryption — খামের ভেতরে চাবি

KMS-কে সব ডেটা পাঠিয়ে encrypt করালে তিনটি সমস্যা হয়। KMS সরাসরি শুধু ছোট ডেটা নেয় (AWS-এ লেখার সময়ে symmetric key-এ প্রায় ৪ KB). ১০ GB ফাইল network-এ আনা-নেওয়া ধীর। আর প্রতিটি কাজে KMS-এর ডাক পড়লে বিলও বাড়ে। সমাধান হলো envelope encryption.

চাবি থাকে দুই স্তরে। Data key (DEK) ডেটাকে encrypt করে, আর প্রতিটি object বা ছোট দলের জন্য আলাদা হতে পারে। Key-encryption key (KEK) শুধু data key-কে encrypt করে, আর KMS-এর ভেতরে থাকে। Encrypt করা data key-কে বলে wrapped key, যা ciphertext-এর পাশেই নিরাপদে রাখা যায়।

এবার একটি বিল লেখা আর পড়ার পুরো পথ দেখুন। মানগুলো নিচের খেলনা কোড থেকে নেওয়া, আসল key এত ছোট হয় না।

এবার নিজে চালান। এখানে KMS একটি ছোট object. XOR-এর এই খেলনা cipher আসল encryption নয়, শুধু পথটি দেখানোর জন্য। বাস্তবে AES-256-GCM-এর মতো পরীক্ষিত algorithm ব্যবহার হয়।

// Envelope flow with a TOY XOR cipher. XOR with a short key is NOT real encryption.
const hex = b => b.map(x => x.toString(16).padStart(2, '0')).join('');
const xor = (bytes, key) => bytes.map((b, i) => b ^ key[i % key.length]);
const bytesOf = s => [...s].map(c => c.charCodeAt(0));
const textOf = b => b.map(c => String.fromCharCode(c)).join('');
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(33);
const newKey = () => Array.from({ length: 4 }, () => Math.floor(rand() * 256));

const kms = { kek: newKey(), allowed: new Set(['app-role']), audit: [],
  check(who, op) { const ok = this.allowed.has(who);
    this.audit.push(`${who} ${op} ${ok ? 'OK' : 'DENIED'}`);
    if (!ok) throw new Error('AccessDenied'); },
  generateDataKey(who) { this.check(who, 'GenerateDataKey'); const plain = newKey();
    return { plain, wrapped: xor(plain, this.kek) }; },
  decrypt(who, wrapped) { this.check(who, 'Decrypt'); return xor(wrapped, this.kek); } };

function write(text) { const dk = kms.generateDataKey('app-role');
  const stored = { wrapped: dk.wrapped, data: xor(bytesOf(text), dk.plain) };
  console.log('plain data key', hex(dk.plain), '(wiped after use)');
  return stored; }
function read(who, obj) { return textOf(xor(obj.data, kms.decrypt(who, obj.wrapped))); }

const bill = write('bill-1042 BDT 750');
console.log('stored wrapped ', hex(bill.wrapped));
console.log('stored data    ', hex(bill.data));
console.log('read by app-role:', read('app-role', bill));
try { read('intern-role', bill); } catch (e) { console.log('read by intern-role:', e.message); }
console.log('audit trail:\n  ' + kms.audit.join('\n  '));

কেন এটি বড় আকারে চলে

• গতি: ডেটার কাজ app-এর পাশেই হয়, আর AES দ্রুত। KMS শুধু ছোট key নিয়ে কাজ করে।
• ক্ষতির সীমা: একটি data key ফাঁস হলে শুধু তার ডেটা খোলা হয়, সব নয়। এটি blast radius ছোট রাখে।
• সহজ re-wrap: KEK বদলাতে ডেটা ছুঁতে হয় না, শুধু খাম নতুন করে সিল করলেই চলে।

শেষেরটির হিসাব দেখুন। ধরে নিই ১ PB ডেটায় ১ কোটি object. সেকেন্ডে ১ GB গতিতে পুরো ডেটা নতুন করে encrypt করতে লাগবে 10¹⁵ ÷ 10⁹ = 10⁶ সেকেন্ড, মানে প্রায় ১১.৬ দিন। অন্যদিকে সেকেন্ডে ১,০০০টি KMS call-এ ১ কোটি wrapped key বদলাতে লাগবে 10,000 সেকেন্ড, মানে প্রায় ২.৮ ঘণ্টা।

গোপন রাখা আর বদল ধরা আলাদা কাজ

Encryption ডেটা লুকায়, কিন্তু ডেটা কেউ বদলেছে কি না, তা আলাদা প্রশ্ন। AES-GCM-এর মতো AEAD এই দুটি কাজ একসাথে করে। Python-এর standard library-তে AES নেই, তাই নিচের কোডে শুধু বদল ধরার অংশটি HMAC দিয়ে দেখানো হলো। এটি encryption নয়, ডেটা খোলাই থাকে।

# Integrity only: HMAC detects a change, it hides nothing.
# Python's standard library has no AES, so this is NOT encryption.
import hashlib
import hmac

KEY = b"demo-key-not-a-real-secret"       # fake, for this demo only


def tag(context, body):
    message = context.encode() + b"\n" + body
    return hmac.new(KEY, message, hashlib.sha256).hexdigest()


def verify(context, body, expected):
    return hmac.compare_digest(tag(context, body), expected)


body = b"bill-1042 amount=750"
saved_tag = tag("tenant=dhaka-shop", body)

print("body stays readable:", body.decode())
print("tag:", saved_tag[:16], "...", len(saved_tag) * 4, "bits")
print("same body        :", verify("tenant=dhaka-shop", body, saved_tag))

changed = b"bill-1042 amount=150"
print("amount changed   :", verify("tenant=dhaka-shop", changed, saved_tag))

print("moved to tenant 2:", verify("tenant=khulna-shop", body, saved_tag))

KEY = b"another-demo-key"
print("different key    :", verify("tenant=dhaka-shop", body, saved_tag))

৫ · KMS call-এর বিল আর data-key caching

Envelope encryption ডেটা KMS-এ পাঠায় না, কিন্তু প্রতিটি object-এ একটি KMS call করলে বিল আর গতি দুটোই ভোগায়। Data-key caching-এ app একটি data key কিছুক্ষণ memory-তে রেখে অনেক object-এ ব্যবহার করে। হিসাব দেখি। সব দাম ধরে নেওয়া, আসল দাম provider-এর pricing পাতায় দেখুন।

• ধরে নিই KMS-এর দাম প্রতি ১০,০০০ call-এ $০.০৩
• চাপ সেকেন্ডে ১০০টি object, ১০টি app instance-এ সমান ভাগে (প্রতিটিতে সেকেন্ডে ১০টি)
• ৩০ দিনের মাস = 2,592,000 সেকেন্ড; প্রতিটি instance-এর নিজের data key

সূত্রটি হলো, মাসিক call = instance × মাসের সেকেন্ড ÷ cache-এর মেয়াদ। দাম নিজের সংখ্যায় বসিয়ে নিন। Provider-ও এই সমস্যা দেখেছে: S3-র Bucket Key একটি bucket-স্তরের মধ্যবর্তী key রেখে KMS call কমায়। AWS Encryption SDK-তেও data-key caching-এর ব্যবস্থা আছে।

৬ · কার হাতে চাবি, rotation আর crypto-erasure

Provider-managed থেকে external key

External key-এর দাম আছে। বাইরের ব্যবস্থা বন্ধ হলে cloud-এর ডেটাও অচল হয়, আর প্রতিটি call-এ latency বাড়ে। তাই এটি শুধু তখনই নিন, যখন নিয়মে সত্যিই দরকার।

HSM (Hardware Security Module) হলো key রাখার জন্য বানানো আলাদা hardware. কেউ খুলতে চাইলে এটি key নষ্ট করে দিতে পারে, আর key-এর কাজ এর ভেতরেই হয়। অনেক provider-এর সাধারণ KMS-এর পেছনেও HSM থাকে, তবে তা বহু গ্রাহকে ভাগ করা। নিজস্ব HSM নেওয়া হয় নিয়মের চাপে, আর এতে পরিচালনার ঝামেলা বাড়ে। মান যাচাইয়ের সাধারণ মানদণ্ড হলো FIPS 140.

Key rotation — কী করে আর কী করে না

Key rotation মানে KEK-এর ভেতরের key material বদলানো। AWS KMS-এ automatic rotation-এ key-এর ID একই থাকে, আর পুরোনো material decrypt-এর জন্য রয়ে যায়। ডিফল্ট মেয়াদ এক বছর, তবে লেখার সময়ে ৯০ থেকে ২,৫৬০ দিনের মধ্যে ঠিক করা যায়। Google Cloud KMS-এ এটি নতুন key version, আর Azure Key Vault-এ rotation policy. Ciphertext-এ লেখা থাকে কোন version লেগেছে, তাই পুরোনো ডেটা পড়া চলতেই থাকে।

Crypto-erasure — চাবি মুছলে ডেটা শেষ

Backup, replica আর snapshot-এ ছড়ানো ডেটা খুঁজে খুঁজে মোছা কঠিন। Crypto-erasure-এ ডেটা নয়, key নষ্ট করা হয়। Key না থাকলে সব ciphertext অর্থহীন। NIST SP 800-88 (Rev. 1, ২০১৪) একে “Cryptographic Erase” নামে স্বীকৃতি দেয়। প্রতি গ্রাহকে আলাদা key থাকলে একজনের ডেটা এভাবে মুছে ফেলা যায়, অন্যদের গায়ে হাত না দিয়েই।

৭ · Secret manager — চলার সময় আনা, config আর dynamic credential

KMS key পাহারা দেয়, কিন্তু database password-এর মতো জিনিস কে রাখবে? Secret manager হলো secret রাখার service. ভেতরে সে সাধারণত KMS দিয়েই encrypt করে। সাথে দেয় version, অনুমতি, log আর rotation-এর ব্যবস্থা।

Config নাকি secret

Twelve-Factor App-এর পরীক্ষাটি কাজের: কোডটি এখনই open source করা গেলে কোনো credential কি ফাঁস হবে? Database-এর ঠিকানা config, password secret. ফিচার চালু-বন্ধের flag config, signing key secret. Config থাকে config-এ, secret থাকে secret manager-এ, আর দুটির অনুমতি আলাদা হয়।

Environment variable config-এর জন্য ভালো। Secret-এর জন্য এটি একটি আপস, কারণ crash dump, debug page, child process আর docker inspect-এ তা দেখা যেতে পারে। সম্ভব হলে app নিজে secret manager থেকে সরাসরি memory-তে আনুক, বা ফাইল হিসেবে tmpfs-এ পাক।

চলার সময় আনা

App-এর কাছে কোনো secret থাকে না, থাকে একটি পরিচয়, যেমন instance role. সেই পরিচয়ে app চালু হওয়ার সময় secret-টি পড়ে। সব provider-এ পথ একই:

aws secretsmanager get-secret-value \
  --secret-id shop/db-password \
  --query SecretString --output text

az keyvault secret show \
  --vault-name shop-vault --name db-password \
  --query value --output tsv

gcloud secrets versions access latest \
  --secret=shop-db-password

vault kv get -field=password secret/shop/db

এই কমান্ডগুলো উদাহরণ মাত্র। আসল ব্যবহারে আউটপুট কখনো log-এ বা terminal-এর history-তে রাখবেন না, আর secret-এর নামই শুধু কোডে থাকবে। নিজে চেষ্টা করলে cloud-এ খরচ হতে পারে, তাই কাজ শেষে পরীক্ষার secret মুছে দিন। HashiCorp Vault (২০১৫) provider-নিরপেক্ষ বিকল্প। ২০২৩ সালে এর license BSL-এ বদলায়, আর সেখান থেকে open source OpenBao fork জন্ম নেয়। Kubernetes-এ secret-এর আলাদা গল্প আছে পর্ব ৪৭-এ, আর CI-এ OIDC পর্ব ৬১-এ।

App-এ cache করার নিয়ম

প্রতিটি request-এ secret manager ডাকলে বিল বাড়ে, গতি কমে, আর সেটি বন্ধ হলে পুরো app থেমে যায়। তাই app secret memory-তে রাখে, এই নিয়মে:

• শুধু memory-তে রাখুন, ফাইল বা log-এ নয়
• একটি TTL দিন, যেমন ১০ মিনিট, আর instance-ভেদে একটু আগে-পরে refresh করুন, যাতে সবাই একসাথে না ডাকে
• Login ব্যর্থ হলে একবার তাজা মান এনে আবার চেষ্টা করুন
• Secret manager সাময়িক বন্ধ থাকলে পুরোনো মানে চলতে থাকুন, আর alert দিন

Dynamic credential — যে password নিজেই মরে যায়

স্থির password যত নিরাপদে রাখুন, সেটি মাসের পর মাস বৈধ থাকে। Dynamic secret অন্য পথ নেয়: app চাইলে Vault সেই মুহূর্তে database-এ একটি নতুন user বানায়, ১ ঘণ্টার মেয়াদে। মেয়াদ শেষে user মুছে যায়।

$ vault read database/creds/shop-app
Key                Value
---                -----
lease_id           database/creds/shop-app/EXAMPLE123
lease_duration     1h
lease_renewable    true
password           EXAMPLE-not-real
username           v-shop-app-EXAMPLE

এটি নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে। লাভ তিনটি: ফাঁস হলেও মেয়াদ অল্প, প্রতিটি instance-এর user আলাদা বলে log-এ কে কী করল বোঝা যায়, আর সন্দেহ হলে একটি lease বাতিল করলেই চলে। দাম হলো, database-এ user তৈরি-মোছার চাপ বাড়ে, আর Vault একটি বাড়তি নির্ভরতা হয়। Cloud-এর database-এ IAM দিয়ে স্বল্পমেয়াদি login-ও একটি বিকল্প, যা provider-ভেদে আলাদা।

৮ · Downtime ছাড়া rotation — একসাথে দুটি বৈধ version

Password একবারে বদলালে কী হয়? Database-এ নতুন password বসল, কিন্তু app-এর cache-এ এখনো পুরোনোটি। নতুন connection খুলতে গেলেই login ব্যর্থ। সমাধান হলো secret rotation-এর সময় কিছুক্ষণ দুটি version-ই বৈধ রাখা।

PostgreSQL-এ লেখার সময়ে একটি user-এর একসাথে দুটি password থাকে না, তাই সাধারণ পথ হলো দুটি user পালা করে ব্যবহার করা। MySQL ৮.০.১৪ থেকে এক user-এ দুটি password রাখা যায় (RETAIN CURRENT PASSWORD). Secrets Manager-এ এই পথের নাম alternating users, আর version-এর লেবেল থাকে AWSCURRENT, AWSPENDING, AWSPREVIOUS.

নিয়মটি ছোট: overlap ≥ cache-এর TTL + rollout-এর সময় + নিরাপত্তার ফাঁক। নিচের সিমুলেটরে ঘড়ি নকল, আর instance-গুলো ২, ৬ আর ৯ মিনিটে refresh করে। প্রথমবার overlap ১৫ মিনিট, দ্বিতীয়বার ৫ মিনিট।

// Two-version password rotation on a simulated clock (minutes, no real time).
// Each app instance re-reads the secret every TTL minutes, at its own offset.
const TTL = 10;
const instances = [['a', 2], ['b', 6], ['c', 9]];

function simulate(overlap) {
  console.log(`--- old password removed ${overlap} min after the switch (TTL ${TTL})`);
  const cached = { a: 'v1', b: 'v1', c: 'v1' };
  let failedMinutes = 0;
  for (let t = 0; t <= 14; t++) {
    const events = [];
    // t = 0: v2 is added to the database, then the secret manager points to v2
    const valid = t < overlap ? ['v1', 'v2'] : ['v2'];
    if (t === 0) events.push('v2 added, secret now points to v2');
    if (t === overlap) events.push('v1 removed from database');
    for (const [name, offset] of instances) {
      if (t % TTL === offset && cached[name] !== 'v2') {
        cached[name] = 'v2';
        events.push(`${name} refreshes to v2`);
      }
    }
    const bad = instances.map(i => i[0]).filter(n => !valid.includes(cached[n]));
    if (bad.length) failedMinutes += bad.length;
    if (events.length || bad.length) {
      const fails = bad.length ? ` | LOGIN FAILS: ${bad.join(',')}` : '';
      console.log(`t=${String(t).padStart(2)} ${events.join('; ') || '-'}${fails}`);
    }
  }
  console.log(`failed instance-minutes: ${failedMinutes}`);
}
simulate(15);
simulate(5);

৯ · Secret ফাঁস হলে — খোঁজা, বাতিল, বদল, তদন্ত

আগে ধরার ব্যবস্থা রাখুন। Commit-এর আগে আর CI-তে secret scanning চলে। আসল scanner-এ অনেক নিয়ম আর এলোমেলোতা মাপার ব্যবস্থা থাকে, তবে মূল ধারণা নিচের script-এই আছে। ফাইলের সব মান নকল, আর AKIAIOSFODNN7EXAMPLE হলো AWS-এর documentation-এর নমুনা।

set -euo pipefail
# All values below are fake. AKIAIOSFODNN7EXAMPLE is AWS's documentation sample.
cat > app.env <<'EOF'
APP_NAME=shop-api
LOG_LEVEL=info
PASSWORD_MIN_LENGTH=12
DB_PASSWORD=Fake-Passw0rd-123
DB_PASSWORD_REF=secret:shop/db-password
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
DATABASE_URL=postgres://app:fakepass@db.example.internal:5432/shop
API_TOKEN=${API_TOKEN}
-----BEGIN EXAMPLE PRIVATE KEY-----
EOF

PATTERNS='AKIA[0-9A-Z]{16}|BEGIN [A-Z ]*PRIVATE KEY|://[^:/]+:[^@]+@|(PASSWORD|SECRET|TOKEN)[A-Z_]*='
ALLOW='_REF=|_LENGTH=|=\$\{'

# Never print the full value: keep the first 4 characters, mask the rest.
mask() { sed -E 's/(=.{4})[^ ]*/\1****/; s#(://[^:]+:)[^@]+@#\1****@#'; }

hits=$(grep -nE "$PATTERNS" app.env | grep -vE "$ALLOW" || true)

echo "findings:"
printf '%s\n' "$hits" | mask
echo "total: $(printf '%s\n' "$hits" | grep -c . || true)"
echo "skipped as safe:"
grep -nE "$ALLOW" app.env | cut -d= -f1

ফাঁস হয়ে গেলে একটি মূল নিয়ম: secret মোছা নয়, secret অকেজো করাই সমাধান। Public repo-তে গেলে ধরে নিন সেটি ইতিমধ্যে কেউ পড়েছে। নিচের ঘটনাটি কাল্পনিক, আর ধাপগুলো শুধু প্রতিরক্ষার।

১০ · AI-এর যুগে secret আর KMS

AI খুব দ্রুত key policy আর rotation script লিখে দেয়। কিন্তু নিরাপত্তার ভুল চলতে চলতে ধরা পড়ে না, পড়ে ক্ষতির পরে।

AI-এর লেখা secret-এর কাজ ব্যবহারের আগে

• কোড, config আর prompt-এ কোনো আসল secret নেই; scanner চালিয়েছি
• প্রতিটি permission official docs-এ মিলিয়েছি; * কেন আছে, ব্যাখ্যা করতে পারি
• Key মোছা, বন্ধ করা বা rotation আগে পরীক্ষার environment-এ চালিয়েছি
• Overlap নিজে হিসাব করেছি, আর পুরোনো version বন্ধের আগে log দেখেছি
• KMS আর secret manager call-এর খরচ গুনেছি, budget alert বসিয়েছি
• Log-এ secret ছাপা হচ্ছে না, তা নিজের চোখে দেখেছি