EC2 থেকে প্রাইভেট RDS: একই VPC, পিয়ারিং নাকি অন্য কিছু?

ডেভেলপারের ল্যাপটপ স্টাফ VPN-এর মাধ্যমে প্রাইভেট RDS ইনস্ট্যান্সে পৌঁছায়, আর EC2-তে থাকা অ্যাপ্লিকেশনটি আদৌ সংযোগ করতে পারে না। এটি ভাঙা ডিপ্লয়মেন্ট নয়। ল্যাপটপের একটি টানেল আছে যা EC2 ইনস্ট্যান্স কখনো উত্তরাধিকার সূত্রে পায় না, আর RDS-এ «প্রাইভেট» মানে ডেটাবেসের কোনো পাবলিক এন্ডপয়েন্ট নেই, মানে এই নয় যে মানুষ VPN ব্যবহারকারীরাই একমাত্র অনুমোদিত কলার। অ্যাপ্লিকেশনটির নিজের অনুমোদিত পথ, নিজের সিকিউরিটি-গ্রুপ সম্পর্ক এবং নিজের ডেটাবেস পরিচয় দরকার, আর এই তিনটি যে ক্রমে বেছে নেবেন তা ডিবাগিংয়ের বেশিরভাগ সময় বাঁচায়। আগে রুট ঠিক করুন, তারপর অনুমতি, তারপর আপনার ডেস্ক থেকে নয়, ডিপ্লয় করা পরিবেশ থেকে যাচাই করুন।

ল্যাপটপের VPN অ্যাপ্লিকেশনের পথ নয়

স্টাফ VPN মানুষদের জন্য যা-ই করুক, কোনো ইনস্ট্যান্সের জন্য এটি কিছুই করে না, যদি না সেই ইনস্ট্যান্স স্পষ্টভাবে একই নেটওয়ার্ক পথের অংশ হয়। প্রাইভেট সাবনেটের একটি EC2 ইনস্ট্যান্স VPC রাউটিং, সিকিউরিটি গ্রুপ এবং নেটওয়ার্ক ACL-এর মাধ্যমে RDS-এ পৌঁছায়। এটি মানুষের টানেল, মানুষের সেশন বা মানুষের ক্রেডেনশিয়াল উত্তরাধিকার সূত্রে পায় না, এবং পাওয়া উচিতও নয়: মানবহীন অ্যাপ্লিকেশন সংযোগ এবং কর্মীদের দূরবর্তী অ্যাক্সেস স্বাধীনভাবে পরিচালনাযোগ্য হওয়া দরকার।

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

সিদ্ধান্ত 1: একই VPC, সরাসরি পথ

যখন অ্যাপ্লিকেশন ও ডেটাবেস একই VPC-তে সরাসরি রাউটিং নিয়ে এবং মাঝখানে কোনো পরিদর্শন ডিভাইস ছাড়া থাকে, পথটি সরল এবং সিকিউরিটি-গ্রুপ রেফারেন্সই সবচেয়ে শক্তিশালী উপলব্ধ হাতিয়ার। অ্যাপ্লিকেশনকে তার নিজের গ্রুপ দিন, তারপর ঠিকানা পরিসরের বদলে সেই গ্রুপ থেকে ডেটাবেস পোর্টের অনুমতি দিন:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

পোর্টটি উদাহরণমাত্র এবং ইঞ্জিনের সঙ্গে মিলতে হবে। গ্রুপ রেফারেন্স অ্যাপ্লিকেশনের ইনস্ট্যান্স থেকে ট্রাফিকের অনুমতি দেয়; এটি তাদের নিয়ম কপি করে না, আর ডেটাবেস লগইন তৈরি করে না। দুটি আলাদা সমস্যা, দুটি আলাদা সমাধান।

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

সিদ্ধান্ত 2: ভিন্ন VPC বা অন্য অ্যাকাউন্ট

অ্যাপ্লিকেশন অন্য VPC-তে থাকলে নেটওয়ার্কের মালিকরা একটি সমর্থিত প্রাইভেট আন্তঃসংযোগ বেছে নেন: পিয়ারিং, ট্রানজিট ডিজাইন বা শেয়ার করা VPC ব্যবস্থা। তখন রাউটিংয়ের দুই দিকই থাকতে হবে, নাম রেজলিউশন RDS এন্ডপয়েন্টের জন্য কাজ করতে হবে, এবং ডেটাবেস নীতি যে সোর্স মূল্যায়ন করে তা প্রকৃতপক্ষে যা আসছে তার সঙ্গে মিলতে হবে। অ্যাকাউন্টের নাম মিলে যাওয়া বা শেয়ার করা বিলিং সম্পর্ক এর কোনোটিই দেয় না।

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

অনুপস্থিত রুট সমাধান করতে ডেটাবেসকে পাবলিকলি অ্যাক্সেসযোগ্য করে তুলবেন না। এটি ভিন্ন মালিকানাধীন ভিন্ন এক্সপোজার সিদ্ধান্ত, এবং সাধারণত যিনি পরিণতি থেকে সবচেয়ে দূরে তিনি এটি প্রস্তাব করেন।

সিদ্ধান্ত 3: ডেটাবেস কোন পরিচয় গ্রহণ করে

নেটওয়ার্ক অ্যাক্সেস এবং ডেটাবেস প্রমাণীকরণ আলাদা স্তর, আর এদের গুলিয়ে ফেলা সবচেয়ে বিভ্রান্তিকর ত্রুটি তৈরি করে। ইনস্ট্যান্স রোল হলো AWS API কল করার জন্য একটি AWS পরিচয়। এটি ডেটাবেস ব্যবহারকারী নয়। IAM ডেটাবেস প্রমাণীকরণ একটি সমর্থিত বৈশিষ্ট্য যেখানে ইঞ্জিন ও কনফিগারেশন অনুমতি দেয়, এবং এটি ডেটাবেস ব্যবহারকারীর প্রতিস্থাপন নয় বরং তার সঙ্গে একটি ম্যাপিং।

একবারের লুকআপ থেকে ধরা ঠিকানার বদলে অ্যাপ্লিকেশনের কনফিগারেশনে RDS এন্ডপয়েন্টের নাম ব্যবহার করুন। Multi-AZ ফেইলওভার সেই নামের পেছনের ঠিকানা বদলে দেয়, আর কোনো IP-তে পিন করা অ্যাপ্লিকেশন ঠিক যখন সেটি সবচেয়ে দরকার তখনই ব্যর্থ হবে। ত্রুটি সরাতে ইঞ্জিনের TLS যাচাই বন্ধ না করে তা চালু রাখুন, কারণ যাচাইয়ের ব্যর্থতা আপনি যে এন্ডপয়েন্টে পৌঁছেছেন সে সম্পর্কে কিছু জানায়।

তারপর ডেটাবেস অ্যাকাউন্টকে অ্যাপ্লিকেশনের প্রয়োজনীয় ন্যূনতম অনুমতি দিন, যে স্কিমা এটি প্রকৃতপক্ষে ব্যবহার করে সেখানেই। এই কাজটি একঘেয়ে, এটি নিরীক্ষাযোগ্য, এবং ঘটনা পর্যালোচনা ঠিক এই অংশটিই জানতে চাইবে।

ডিপ্লয় করা পরিবেশ থেকে যাচাই করুন

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

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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