paint-brush
একটি ওয়েব প্রকল্প তৈরি করার আগে নিজেকে জিজ্ঞাসা করার জন্য পাঁচটি প্রশ্নদ্বারা@shcherbanich
1,528 পড়া
1,528 পড়া

একটি ওয়েব প্রকল্প তৈরি করার আগে নিজেকে জিজ্ঞাসা করার জন্য পাঁচটি প্রশ্ন

দ্বারা Filipp Shcherbanich9m2024/08/01
Read on Terminal Reader

অতিদীর্ঘ; পড়তে

ওয়েব প্রকল্প অনেক কারণে ব্যর্থ হতে পারে. এই নিবন্ধে আমি আমার অভিজ্ঞতা শেয়ার করব যা আপনাকে তাদের কিছু সমাধান করতে সহায়তা করবে।
featured image - একটি ওয়েব প্রকল্প তৈরি করার আগে নিজেকে জিজ্ঞাসা করার জন্য পাঁচটি প্রশ্ন
Filipp Shcherbanich HackerNoon profile picture
0-item
1-item

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

1. আপনার কোডে কি কোন গোপনীয়তা সংরক্ষিত আছে?

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


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


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


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


সমাধান: এখনই আপনার প্রজেক্ট চেক করুন


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


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


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

2. আপনি আপনার লাইব্রেরি লাইসেন্স সম্পর্কে কি জানেন?

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


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


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


সমাধান: স্বয়ংক্রিয় চেক এবং আপডেট ব্যবহার করুন


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


এবং যখন আপনি নির্ভরতা আপডেট করেন তখন এই কমান্ডগুলিকে কল করতে ভুলবেন না (এই চেকগুলিকে স্বয়ংক্রিয় করা আরও ভাল), কারণ একটি সংযুক্ত লাইব্রেরির লাইসেন্স নতুন সংস্করণে পরিবর্তন হতে পারে।

3. আপনার বিকাশ সংস্করণ অ্যাক্সেস সীমাবদ্ধ?

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


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


নিরাপত্তা ঝুঁকির বাইরে, ডুপ্লিকেট ওয়েব পেজ সার্চ ইঞ্জিন র‌্যাঙ্কিংকে নেতিবাচকভাবে প্রভাবিত করতে পারে। Google এর মতো সার্চ ইঞ্জিনগুলি এই সদৃশগুলিকে অবাঞ্ছিত সামগ্রী হিসাবে দেখতে পারে, সম্ভাব্যভাবে আপনার প্রকল্পের মূল পৃষ্ঠাগুলির র‌্যাঙ্কিং কমিয়ে দিতে পারে বা এমনকি সূচী থেকে সম্পূর্ণরূপে সরিয়ে দিতে পারে৷


সমাধান: শুরু থেকেই আপনার নিরাপত্তা কৌশল তৈরি করুন


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


সমস্ত পরীক্ষার সংস্করণে অ্যাক্সেস সীমাবদ্ধ করুন। নিশ্চিত করুন যে dev, QA, স্টেজিং এবং অন্যান্য সংস্করণ সর্বজনীনভাবে অ্যাক্সেসযোগ্য নয়। উদাহরণস্বরূপ, একটি VPN এর মাধ্যমে অ্যাক্সেসযোগ্য হওয়ার জন্য সেগুলিকে কনফিগার করুন৷ এটি অননুমোদিত অ্যাক্সেসের সম্ভাবনা হ্রাস করে, এমনকি যদি পরীক্ষার ডোমেনটি দূষিত অভিনেতাদের কাছে পরিচিত হয়।


পরীক্ষার সংস্করণগুলিকে ইন্ডেক্স করা থেকে রক্ষা করুন। এমনকি যদি আপনার পরীক্ষার সংস্করণগুলি শুধুমাত্র VPN এর মাধ্যমে অ্যাক্সেসযোগ্য হয় এবং পৃথক গোপন ডোমেনে হোস্ট করা হয়, তাহলে একটি `robots.txt` ফাইল বা `noindex` মেটা ট্যাগ ব্যবহার করে সার্চ ইঞ্জিন ইন্ডেক্সিং থেকে রক্ষা করুন। এই পদক্ষেপটি অত্যন্ত গুরুত্বপূর্ণ, কারণ অনুসন্ধান ইঞ্জিনগুলি কখনও কখনও অপ্রত্যাশিত উপায়ে এই পৃষ্ঠাগুলি খুঁজে পেতে এবং সূচী করতে পারে৷

4. আপনার আসল আইপি ঠিকানা কি লুকানো আছে? আপনার অব্যবহৃত পোর্ট বন্ধ আছে?

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


  • DDoS আক্রমণ: আপনার প্রকল্পের আসল IP ঠিকানা জেনে আক্রমণকারীরা আপনার সার্ভারে একটি ডিস্ট্রিবিউটেড ডিনায়াল অফ সার্ভিস (DDoS) আক্রমণ চালাতে পারে। উদাহরণস্বরূপ, ক DNS প্রতিফলন পরিবর্ধন আক্রমণ পাবলিক ডিএনএস সার্ভার থেকে প্রচুর পরিমাণে প্রতিক্রিয়ার সাথে আপনার সার্ভারকে অভিভূত করতে পারে, আপনার পরিষেবাটি ব্যবহারকারীদের কাছে অনুপলব্ধ করে এবং উল্লেখযোগ্য আর্থিক ক্ষতির কারণ হতে পারে।


  • সম্ভাব্য দুর্বলতা সনাক্ত করা: গুরুতর হ্যাকাররা, শুধুমাত্র অপেশাদার নয়, দুর্বলতাগুলি খুঁজে পেতে এবং শোষণ করতে খোলা পোর্ট এবং নেটওয়ার্ক-উন্মুক্ত সফ্টওয়্যার স্ক্যান করতে পারে। এমনকি MongoDB-এর মতো সুপরিচিত পরিষেবাগুলি ভুল কনফিগারেশনের কারণে উল্লেখযোগ্য ডেটা লঙ্ঘন করেছে। এই সমস্যাগুলির অনেকগুলি কেবল আসল আইপি ঠিকানা লুকিয়ে রেখে এড়ানো যেতে পারে।


সমাধান: সম্ভাব্য আক্রমণকারীর জীবনকে আরও জটিল করে তুলুন


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


যদিও এই সরঞ্জামগুলি উল্লেখযোগ্যভাবে নিরাপত্তা বাড়াতে পারে, মনে রাখতে অতিরিক্ত বিবেচনা রয়েছে:

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


  • আইপি ইতিহাস এবং Whois অনুরোধ: যেমন সেবা DNS ইতিহাস বা Whois অনুরোধ একটি ডোমেনের সাথে সম্পর্কিত ঐতিহাসিক আইপি ঠিকানা প্রকাশ করতে পারে। যদি আপনার আসল আইপি কখনও আপনার কাজের ডোমেনের সাথে লিঙ্ক করা থাকে তবে আপনার এটি পরিবর্তন করা উচিত।


  • DDoS সুরক্ষা এবং API এন্ডপয়েন্ট: API এন্ডপয়েন্ট হিসাবে পরিবেশন করা ডোমেনের জন্য DDoS সুরক্ষা ব্যবহার করার সময় সতর্ক থাকুন। সুরক্ষা সিস্টেমগুলি ব্যবহারকারীর যাচাইকরণের পদক্ষেপগুলি প্রবর্তন করতে পারে যা HTML কোডের সাথে JSON/XML প্রতিক্রিয়াগুলি প্রতিস্থাপন করে আপনার ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনগুলির কার্যকারিতা ব্যাহত করতে পারে৷


  • বহির্গামী API অনুরোধ: যখন আপনার সার্ভার তৃতীয় পক্ষের API-কে অনুরোধ পাঠায়, তখন এটি অসাবধানতাবশত তার IP ঠিকানা প্রকাশ করতে পারে। এই ধরনের অনুরোধের জন্য প্রক্সি সার্ভার ব্যবহার করা সাহায্য করতে পারে, কারণ আক্রমণের পরবর্তী পরিস্থিতি মোকাবেলা করার চেয়ে প্রক্সি পরিবর্তন করা সহজ।


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


আলাদা সার্ভারে ডাটাবেস ম্যানেজমেন্ট সিস্টেম (DBMS) বা অন্যান্য অভ্যন্তরীণ পরিষেবাগুলির জন্য, নিশ্চিত করুন যে অ্যাক্সেস নির্দিষ্ট IP ঠিকানাগুলিতে সীমাবদ্ধ রয়েছে যা আপনি কঠোরভাবে নিয়ন্ত্রণ করেন। এই সেটআপটি সমালোচনামূলক সিস্টেমগুলিতে অননুমোদিত অ্যাক্সেসকে বাধা দেয়, একটি অতিরিক্ত সুরক্ষা স্তর যুক্ত করে এবং বাহ্যিক আক্রমণ এবং ডেটা ফাঁসের ঝুঁকি হ্রাস করে।

5. আপনি কি প্রকল্প নির্ভরতা এবং সফ্টওয়্যার আপডেট করেন?

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


সমাধান: আপনার আপডেট স্বয়ংক্রিয়


আপনাকে ম্যানুয়ালি সবকিছু আপডেট করার দরকার নেই; অনেক অটোমেশন টুল সাহায্য করতে পারে। উদাহরণ স্বরূপ, ডিপেন্ডাবট GitHub-এ স্বয়ংক্রিয়ভাবে পুরানো বা দুর্বল নির্ভরতা সনাক্ত করে এবং আপডেটের পরামর্শ দেয়।


নিরাপত্তা শংসাপত্রের স্বয়ংক্রিয় পুনর্নবীকরণও গুরুত্বপূর্ণ। ব্যবহার করলে আসুন এনক্রিপ্ট করি সার্টিফিকেট, আপনি তাদের পুনর্নবীকরণ স্বয়ংক্রিয় করতে পারেন সার্টবট . মেয়াদোত্তীর্ণ শংসাপত্রগুলি কিছু সত্যিকারের ব্যথার কারণ হতে পারে, তবে তাদের পুনর্নবীকরণ স্বয়ংক্রিয় করা একটি সহজ কাজ।

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

সর্বশেষ ভাবনা

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


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


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