গিটহাব অ্যাকশনের জন্য ব্যবহারিক নিরাপত্তা কঠোরীকরণ

হোম » পাইথন » গিটহাব অ্যাকশনের জন্য ব্যবহারিক নিরাপত্তা কঠোরীকরণ

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

এই নির্দেশিকাটি GitHub অ্যাকশনগুলিকে এন্ড-টু-এন্ড সুরক্ষিত করার জন্য একটি বিস্তৃত, মতামতভিত্তিক চেকলিস্টের মধ্য দিয়ে যায়।: গোপন তথ্য সঠিকভাবে কীভাবে পরিচালনা করবেন, স্ক্রিপ্ট ইনজেকশন এড়াবেন, টোকেন এবং ট্রিগারগুলি কীভাবে লক করবেন, তৃতীয় পক্ষের ক্রিয়াকলাপ মূল্যায়ন করবেন, রানারদের পরিচালনা করবেন এবং কোড স্ক্যানিং, OIDC, Dependabot এবং অডিট লগের মতো অন্তর্নির্মিত সুরক্ষা বৈশিষ্ট্যগুলির সুবিধা গ্রহণ করবেন। লক্ষ্য হল ছড়িয়ে ছিটিয়ে থাকা সেরা অনুশীলনগুলি, সাম্প্রতিক ঘটনাগুলি থেকে কঠোরভাবে অর্জিত শিক্ষা এবং GitHub-এর নিজস্ব কঠোর নির্দেশিকাকে একটি একক, ব্যবহারিক রেফারেন্সে একত্রিত করা যা আপনি বাস্তব প্রকল্পগুলিতে প্রয়োগ করতে পারেন।

গিটহাব অ্যাকশনের আসল ঝুঁকি প্রোফাইল

উচ্চ স্তরে, একটি GitHub Actions ওয়ার্কফ্লো হল কেবল একটি YAML ফাইল যার অধীনে .github/workflows যা এক বা একাধিক কাজকে সংজ্ঞায়িত করে, প্রতিটি ধাপের সমন্বয়ে গঠিত। ধাপগুলি হয় শেল কমান্ড চালাতে পারে অথবা GitHub বা সম্প্রদায় দ্বারা প্রকাশিত পুনর্ব্যবহারযোগ্য ক্রিয়াগুলি আহ্বান করতে পারে। পুশ, পুল অনুরোধ, ইস্যু কার্যকলাপ, সময়সূচী বা ম্যানুয়াল প্রেরণের মতো ইভেন্টগুলির মাধ্যমে কর্মপ্রবাহগুলি ট্রিগার হয়।

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

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

সাম্প্রতিক বাস্তব-বিশ্বের ঘটনাগুলি আন্ডারলাইন করেছে যে আক্রমণাত্মক পৃষ্ঠ হিসাবে গিটহাব অ্যাকশন কতটা আকর্ষণীয়।। আক্রমণকারীরা প্রকাশিত প্যাকেজগুলিতে ক্রিপ্টোমাইনার প্রবেশ করানোর জন্য দুর্বল কর্মপ্রবাহের অপব্যবহার করেছে, এবং জনপ্রিয় tj-actions/changed-files কয়েনবেসে পৌঁছানোর চেষ্টা করা একটি বহু-পর্যায়ের আক্রমণে কর্মক্ষমতা বিঘ্নিত হয়েছে। ক্ষতিকারক কোডটি কর্মপ্রবাহ থেকে গোপন তথ্য বের করে বিল্ড লগে লিখেছিল, যার ফলে ফলো-অন সাপ্লাই চেইন বিঘ্নের সম্ভাব্য ঝুঁকি তৈরি হয়েছিল।

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

GitHub অ্যাকশনে গোপন তথ্য লক করা

যেকোনো CI/CD সিস্টেমে গোপনীয়তা সাধারণত সবচেয়ে আকর্ষণীয় লক্ষ্যবস্তু।। GitHub Actions-এ এগুলি রিপোজিটরি, অর্গানাইজেশন বা এনভায়রনমেন্ট সিক্রেট হিসেবে দেখা যায়, এবং অ্যাড-হক ভ্যালু হিসেবে আপনি ভুলবশত কনফিগারেশন, লগ, ক্যাশে বা আর্টিফ্যাক্টে ডাম্প করতে পারেন।

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

সেই মডেলের অধীনে গোপনীয়তা টিকে থাকতে, এই মৌলিক নিয়মগুলি অনুসরণ করুন:

• ন্যূনতম সুযোগ-সুবিধার নীতি প্রয়োগ করুন: ওয়ার্কফ্লোতে ব্যবহৃত যেকোনো শংসাপত্রের কেবলমাত্র প্রয়োজনীয় ন্যূনতম অনুমতি থাকতে হবে। ওয়ার্কফ্লো গোপনীয়তা হিসাবে সাধারণ-উদ্দেশ্য অ্যাডমিন টোকেন শেয়ার করা এড়িয়ে চলুন।
• সংবেদনশীল মূল্যবোধের জন্য সংগ্রহস্থল বা প্রতিষ্ঠানের গোপনীয়তার চেয়ে পরিবেশগত গোপনীয়তা পছন্দ করুন। পরিবেশগত গোপনীয়তা কেবলমাত্র সেই চাকরির জন্য উপলব্ধ যারা সেই পরিবেশ ঘোষণা করে, এবং আপনি এগুলিকে প্রয়োজনীয় পর্যালোচক এবং শাখা বিধিনিষেধের মতো অতিরিক্ত সুরক্ষার মধ্যে আবৃত করতে পারেন।
• ওয়ার্কফ্লো YAML ফাইলগুলিতে কখনও গোপনীয়তা প্লেইন টেক্সটে সংরক্ষণ করবেন না। অথবা রেপোতে চেক করা কোডে। সংবেদনশীল সবকিছুই GitHub Secrets প্রক্রিয়া অথবা একটি বহিরাগত গোপন ব্যবস্থাপকের মাধ্যমে যেতে হবে।
• একক গোপন মান হিসেবে স্ট্রাকচার্ড ব্লব (JSON, YAML, XML) ব্যবহার করা এড়িয়ে চলুন। মাস্কিং মূলত সঠিক স্ট্রিং ম্যাচিংয়ের উপর নির্ভর করে; মাল্টি-ফিল্ড ব্লবগুলি নির্ভরযোগ্যভাবে সম্পাদনা করা অনেক কঠিন। পরিবর্তে, সংবেদনশীল ডেটাকে একাধিক ডেডিকেটেড গোপন এন্ট্রিতে বিভক্ত করুন।
• সমস্ত প্রাপ্ত গোপনীয়তা স্পষ্টভাবে নিবন্ধন করুন। যদি আপনি কোন গোপন তথ্য (Base64, URL-encode, JWT signing, ইত্যাদি) রূপান্তর করেন এবং সেই ফলাফল কখনও লগে আঘাত করতে পারে, তাহলে রূপান্তরিত মানটিকে তার নিজস্ব গোপন তথ্য হিসেবে নিবন্ধন করুন যাতে GitHub এটিকে আড়াল করার চেষ্টা করতে পারে।

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

স্ক্রিপ্ট ইনজেকশন এবং অনিরাপদ ইন্টারপোলেশন এড়ানো

GitHub Actions বাগের সবচেয়ে সাধারণ, কিন্তু সূক্ষ্ম, শ্রেণীগুলির মধ্যে একটি হল এক্সপ্রেশনের মাধ্যমে স্ক্রিপ্ট ইনজেকশন. GitHub সমৃদ্ধ "প্রসঙ্গ" প্রদান করে যেমন github, env, secrets এবং ইভেন্ট পেলোড, যা আপনি ওয়ার্কফ্লোতে ব্যবহার করে উল্লেখ করেন ${{ ... }} সিনট্যাক্স। এই এক্সপ্রেশনগুলি GitHub দ্বারা মূল্যায়ন করা হয় আগে তোমার শেল স্টেপ দৌড়ে।

যখন আপনি একটি অবিশ্বস্ত প্রসঙ্গ সরাসরি একটি শেল কমান্ডে এম্বেড করেন, তখন আপনি কমান্ড ইনজেকশনকে আমন্ত্রণ জানানউদাহরণস্বরূপ, যদি আপনি করেন:

run: echo "new issue ${{ github.event.issue.title }} created"

এবং একজন আক্রমণকারী ইস্যুর শিরোনাম নিয়ন্ত্রণ করতে পারে, তারা একটি শিরোনাম জমা দিতে পারে যেমন $(id)। রাশি মূল্যায়নের পর ধাপটি হবে:

echo "new issue $(id) created"

যা কার্যকর করে id রানারের উপর। শেলে যতই কোট পরিবর্তন করা হোক বা সহজ বৈধতা যোগ করা হোক না কেন, আপনাকে এই প্যাটার্ন থেকে নির্ভরযোগ্যভাবে রক্ষা করতে পারবে না।

GitHub যে নিরাপদ প্যাটার্নটি সুপারিশ করে তা হল একটি মধ্যবর্তী পরিবেশ পরিবর্তনশীল ব্যবহার করা।:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

এখানে সম্ভাব্য প্রতিকূল মানটি পরিবেশ পরিবর্তনশীল হিসাবে মেমরিতে থাকে, এবং খোলসটি কেবল দেখতে পায় $TITLE, একটি গতিশীলভাবে নির্মিত কমান্ড লাইন নয়। আপনার এখনও স্বাভাবিক শেল হাইজিন প্রয়োজন (ভেরিয়েবল উদ্ধৃত করা, অপ্রয়োজনীয় eval এড়ানো, ইত্যাদি), কিন্তু বিপজ্জনক ইন্টারপোলেশন ধাপটি সরানো হয়েছে।

যখনই আপনি এম্বেড করতে প্রলুব্ধ হন ${{ github.* }} অথবা অন্যান্য ব্যবহারকারী-নিয়ন্ত্রিত ডেটা সরাসরি run: ব্লক করে, থামাও এবং ঠেলে দাও env: পরিবর্তে। এই একটি অভ্যাস আপনার কর্মপ্রবাহ জুড়ে স্ক্রিপ্ট-ইনজেকশন সমস্যাগুলির একটি সম্পূর্ণ শ্রেণীকে দূর করে।

অনুমতি এবং টোকেন নিরাপদে কনফিগার করা

সার্জারির GITHUB_TOKEN প্রতিটি ওয়ার্কফ্লো রানে GitHub যে ইনজেক্ট করে তা অবিশ্বাস্যভাবে শক্তিশালী, যদি ডিফল্ট অবস্থায় থাকে। এটি বিভিন্নভাবে বিষয়বস্তু পড়তে এবং লিখতে পারে, পুল রিকোয়েস্ট খুলতে এবং আপডেট করতে পারে এবং রেপোর সাথে ইন্টারঅ্যাক্ট করতে পারে। ঐতিহাসিকভাবে, অনেক প্রতিষ্ঠান অজান্তেই এটিকে পঠন-লেখার জন্য ডিফল্ট করে রেখেছিল।

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

permissions:
contents: read
pull-requests: write

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

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

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

তৃতীয় পক্ষের ক্রিয়াকলাপ নির্বাচন এবং পিন করা

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

তৃতীয় পক্ষের পদক্ষেপ গ্রহণের সময় আপনি প্রতিরক্ষার বেশ কয়েকটি স্তর প্রয়োগ করতে পারেন।:

• একটি ছোট, বিশ্বস্ত অ্যালাউলিস্ট থেকে শুরু করুন. GitHub-রক্ষণাবেক্ষণকৃত ক্রিয়া (যেমন actions/checkout, actions/setup-node) এবং যাচাইকৃত নির্মাতাদের কাছ থেকে মার্কেটপ্লেস অ্যাকশনগুলি সাধারণত র‍্যান্ডম রিপোর তুলনায় নিরাপদ বেসলাইন। অনেক সংস্থা অর্গ লেভেলে "নির্দিষ্ট অ্যাকশন এবং পুনঃব্যবহারযোগ্য কর্মপ্রবাহের অনুমতি দিন" এর মাধ্যমে এটি প্রয়োগ করে।
• জনপ্রিয়, সক্রিয়ভাবে রক্ষণাবেক্ষণ করা কর্মকাণ্ডের পক্ষে থাকুন। গবেষণায় দেখা গেছে যে অনেক মার্কেটপ্লেস অ্যাকশনের OpenSSF স্কোরকার্ড স্কোর কম, একক রক্ষণাবেক্ষণকারী এবং স্বল্পস্থায়ী বা খুব কম বয়সী মালিকের অ্যাকাউন্ট থাকে। ব্যাপকভাবে ব্যবহৃত অ্যাকশনগুলি আরও বেশি তদন্ত এবং দ্রুত সংশোধন জমা করার প্রবণতা রাখে।
• অ্যাকশনের রেপোতে প্রচুর সংখ্যক খোলা Dependabot PR-এর জন্য নজর রাখুন।। এটি প্রায়শই একটি লক্ষণ যে রক্ষণাবেক্ষণকারী সুরক্ষা আপডেট প্রয়োগ করছেন না, যার ফলে ট্রানজিটিভ দুর্বলতাগুলি অপ্রকাশিত থাকে।
• একাধিক রক্ষণাবেক্ষণকারী এবং একটি অ-সংরক্ষণাগারযুক্ত, সক্রিয় কোডবেস সহ ক্রিয়াকলাপ পছন্দ করুন। বাজারে শত শত ক্রিয়াকলাপ সংরক্ষণাগারভুক্ত করা হয়, যার অর্থ কোনও নতুন সংশোধন বা সামঞ্জস্য আপডেট নেই এবং সময়ের সাথে সাথে ঝুঁকি বৃদ্ধি পাচ্ছে।

ভার্সন পিনিং আরেকটি গুরুত্বপূর্ণ বিষয়. যদি আপনি শুধুমাত্র ট্যাগ দ্বারা একটি ক্রিয়া নির্দিষ্ট করেন, যেমন some-org/some-action@v2, আপনি বিশ্বাস করছেন যে ট্যাগটি কখনই ক্ষতিকারক কোডে স্থানান্তরিত হয় না। রক্ষণাবেক্ষণকারী অ্যাকাউন্ট বা সংগ্রহস্থলের সাথে আপোস করা হলে ট্যাগগুলিকে পুনরায় লক্ষ্যবস্তু করা যেতে পারে।

আজকের দিনে সবচেয়ে রক্ষণাত্মক পদ্ধতি হলো একটি পূর্ণাঙ্গ কমিট SHA-তে পিন করা।:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

SHA তে পিন করলে কোডটি আপনার দৃষ্টিকোণ থেকে কার্যকরভাবে অপরিবর্তনীয় হয়ে ওঠে। (Git অবজেক্টের উপর SHA-1 সংঘর্ষের আক্রমণের মতো নয়)। এর নেতিবাচক দিকটি কার্যকরী: নতুন বৈশিষ্ট্য বা সংশোধনের সময় আপনাকে SHA আপডেট করতে হবে, এবং আপনি যদি সতর্ক না হন তবে বিভিন্ন কর্মপ্রবাহ বিভিন্ন SHA-তে প্রবাহিত হতে পারে।

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

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

নিরাপদ কর্মপ্রবাহ এবং চাকরির নকশা করা

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

কাজকে আলাদা আলাদা কাজে এবং এমনকি আলাদা কর্মপ্রবাহে বিভক্ত করলে বিচ্ছিন্নতা এবং স্পষ্টতা উভয়ই পাওয়া যায়।উদাহরণস্বরূপ, আপনার কাছে থাকতে পারে:

• A নির্মাণ এবং পরীক্ষার কাজ যা ন্যূনতম অনুমতি ছাড়াই চলে এবং কোনও স্থাপনার গোপনীয়তা নেই।
• A প্যাকেজ কাজ যেটি স্বাক্ষরিত শিল্পকর্ম তৈরি করে কিন্তু তবুও প্রোডাকশনের সাথে কথা বলে না।
• A কাজ স্থাপন করুন যা অন্যদের উপর নির্ভর করে এবং পরিবেশগত গোপনীয়তা অ্যাক্সেস করার এবং মেঘের ভূমিকা গ্রহণ করার একমাত্র অনুমোদিত।

GitHub-হোস্টেড রানারগুলিতে, একটি ওয়ার্কফ্লোতে প্রতিটি কাজ একটি নতুন VM-তে চলে, যা আপনাকে কাজের মধ্যে কিছুটা বিচ্ছিন্নতা দেয়। এটি একটি শক্ত স্যান্ডবক্সের সমতুল্য নয়, এবং পরিচিত ক্রস-জব ভেক্টর (যেমন শেয়ার্ড ব্রাঞ্চ ক্যাশে) আছে, কিন্তু কাজ বিভক্ত করা এখনও আক্রমণকারীদের আরও কঠোর পরিশ্রম করতে বাধ্য করে এবং সম্পর্কহীন ধাপে গোপন তথ্যের দুর্ঘটনাজনিত ফাঁস হ্রাস করে।

সংবেদনশীল পদক্ষেপগুলিকে সুরক্ষার সাথে সংযুক্ত করতে পরিবেশ ব্যবহার করুনএকটি স্থাপনার কাজ ঘোষণা করতে পারে:

environment: production

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

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

• গোপন তথ্যগুলো ক্যাশে জমা করো না, বিশেষ করে অপ্রচলিত স্থান যেমন ~/.docker/config.json যাতে সাধারণ ডকার শংসাপত্র থাকতে পারে।
• গোপন তথ্য লগ করা বা সম্পূর্ণ প্রসঙ্গ লগে ডাম্প করা এড়িয়ে চলুন, কারণ এটি মাস্কিংকে পরাজিত করতে পারে বা প্রাপ্ত মানগুলি প্রকাশ করতে পারে যা GitHub সম্পাদনা করতে জানে না।
• মনে রাখবেন যে রেপোতে পড়ার অ্যাক্সেস আছে এমন যে কেউ সাধারণত আর্টিফ্যাক্ট ডাউনলোড করতে এবং লগ ব্রাউজ করতে পারে।, যদি আপনি বাইরের সহযোগীদের অ্যাক্সেস দেন তবে তাদের অন্তর্ভুক্ত করুন।

OIDC এবং স্বল্পস্থায়ী ক্লাউড শংসাপত্র

আপনি যে সবচেয়ে প্রভাবশালী পরিবর্তনগুলি করতে পারেন তার মধ্যে একটি হল দীর্ঘস্থায়ী ক্লাউড প্রোভাইডার শংসাপত্রগুলিকে GitHub গোপনীয়তা হিসাবে সম্পূর্ণরূপে সংরক্ষণ করা বন্ধ করা।। পরিবর্তে, একটি নির্দিষ্ট কর্মপ্রবাহ পরিচয়ের সাথে আবদ্ধ স্বল্পস্থায়ী, সু-স্কোপযুক্ত টোকেন পেতে OpenID Connect (OIDC) ব্যবহার করুন।

উচ্চ-স্তরের প্রবাহ সহজ:

• আপনার ক্লাউড প্রোভাইডার (AWS, Azure, GCP, ইত্যাদি) GitHub এর OIDC প্রোভাইডারকে বিশ্বাস করার জন্য কনফিগার করা হয়েছে।
• আপনি একটি পরিচয় নীতি সংজ্ঞায়িত করেন যা বলে "শুধুমাত্র এই সংস্থা/রেপো/শাখা বা পরিবেশ থেকে টোকেন গ্রহণ করুন"।
• কোনও কাজের সময়, GitHub একটি OIDC টোকেনের অনুরোধ করতে পারে এবং আপনার কর্মপ্রবাহ একটি ক্লাউড-নির্দিষ্ট ক্রিয়া ব্যবহার করে (উদাহরণস্বরূপ aws-actions/configure-aws-credentials) একটি স্বল্পস্থায়ী ভূমিকা বা পরিষেবা অ্যাকাউন্ট টোকেনের জন্য এটি বিনিময় করতে।

বিশ্বাসের অবস্থা হল যেখানে আপনি খুব সূক্ষ্মভাবে পেতে পারেন। AWS-এর জন্য, একটি সাধারণ নীতিতে অন্তর্ভুক্ত থাকতে পারে:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

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

OIDC ব্যবহার করলে ক্লাউডে ন্যূনতম বিশেষাধিকার ভূমিকা নীতির প্রয়োজনীয়তা দূর হয় না।, কিন্তু এটি GitHub Secrets-এ থাকা স্ট্যাটিক অ্যাক্সেস কীগুলিকে সরিয়ে দেয়, যেখানে সেগুলি চুরি করা যেতে পারে এবং GitHub-এর বাইরে থেকে অনির্দিষ্টকালের জন্য পুনঃব্যবহার করা যেতে পারে।

শাখা সুরক্ষা, নিয়মাবলী এবং পরিবেশ একসাথে কাজ করা

গিটহাব অ্যাকশনের অনেক ভীতিকর আক্রমণের পথ "আক্রমণকারী একটি সুরক্ষিত শাখায় ক্ষতিকারক পরিবর্তন ইনজেক্ট করে" - এই পর্যন্তই সীমাবদ্ধ।। শাখা সুরক্ষা এবং নিয়ম সেটগুলি সেখানে আপনার প্রতিরক্ষার প্রধান লাইন।

যেমন শাখায় main or production, আপনি সাধারণত অন্তত চান:

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

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

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

রানারদের পরিচালনা: GitHub-হোস্টেড বনাম স্ব-হোস্টেড

রানাররা হল সেই মেশিন যা আসলে আপনার কর্মপ্রবাহ সম্পাদন করে। GitHub-হোস্টেড রানার হল GitHub দ্বারা পরিচালিত ক্ষণস্থায়ী VM; স্ব-হোস্টেড রানার হল এমন মেশিন বা কন্টেইনার যা আপনি সরবরাহ এবং নিয়ন্ত্রণ করেন।

GitHub-হোস্টেড রানাররা সাধারণত ডিফল্টভাবে অনেক বেশি নিরাপদ।:

• এগুলি ক্ষণস্থায়ী এবং প্রতিটি কাজের জন্য পুনরায় সেট করা হয়, তাই রান জুড়ে কোনও স্থায়ী আপস নেই।
• গিটহাব স্ট্যান্ডার্ড ছবির জন্য SBOM প্রকাশ করে (উবুন্টু, উইন্ডোজ, ম্যাকওএস), আপনাকে দুর্বলতার জন্য পূর্বে ইনস্টল করা সফ্টওয়্যার বিশ্লেষণ করতে দেয়।
• কিছু ক্ষতিকারক হোস্টকে বাক্সের বাইরে ব্লক করা হয়েছে (উদাহরণস্বরূপ পরিচিত ক্রিপ্টোমাইনিং পুল) এর মাধ্যমে /etc/hosts কনফিগারেশন.

স্ব-হোস্টেড দৌড়বিদরা শক্তিশালী কিন্তু বিপজ্জনক যদি আপনি তাদের প্রোডাকশন সার্ভারের মতো আচরণ না করেন:

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

যদি আপনাকে স্ব-হোস্টেড রানার ব্যবহার করতেই হয়, তাহলে তাদের বিশ্বাসের সীমানা দিয়ে খোদাই করুন।রানার গ্রুপ এবং সীমাবদ্ধতা ব্যবহার করুন যাতে:

• সরকারি এবং বেসরকারি প্রকল্পগুলি কখনই একই রানার পুল ভাগ করে না।
• উচ্চ সংবেদনশীলতা রেপোগুলির (যেমন উৎপাদন পরিকাঠামো) নিজস্ব কঠোরভাবে নিয়ন্ত্রিত রানার রয়েছে।
• শুধুমাত্র নির্দিষ্ট সংগ্রহস্থল বা সংস্থাগুলি একটি নির্দিষ্ট গোষ্ঠীতে কাজ পাঠাতে পারে।

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

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

অন্তর্নির্মিত নিরাপত্তা বৈশিষ্ট্য: কোড স্ক্যানিং, স্কোরকার্ড এবং ডিপেন্ডাবট

GitHub বিশেষভাবে কর্মপ্রবাহ এবং নির্ভরতা ঝুঁকি মোকাবেলার লক্ষ্যে বেশ কয়েকটি প্রথম-শ্রেণীর বৈশিষ্ট্য সরবরাহ করে।, এবং এগুলোর সেটআপ খরচ কম।

কোড স্ক্যানিং (উদাহরণস্বরূপ CodeQL এর মাধ্যমে) এখন GitHub Actions এর কর্মপ্রবাহ নিজেই বিশ্লেষণ করতে পারে, কেবল আপনার অ্যাপ্লিকেশন উৎস নয়। "অতিরিক্ত গোপনীয়তা এক্সপোজার" এর মতো নিয়মগুলি এমন প্যাটার্নগুলি সনাক্ত করতে পারে যেখানে GitHub কোন গোপনীয়তাগুলি প্রয়োজন তা নির্ধারণ করতে পারে না (উদাহরণস্বরূপ, গতিশীল secrets[myKey] ম্যাট্রিক্স বিল্ডে ব্যবহার), যার ফলে এটি জব মেমোরিতে প্রয়োজনের তুলনায় বেশি গোপন তথ্য লোড করে।

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

• নির্ভরতা পিন করা হচ্ছে না।
• শাখা সুরক্ষা বা কোড পর্যালোচনার প্রয়োজনীয়তা অনুপস্থিত।
• নিরাপত্তা নীতি বা দুর্বলতা প্রতিক্রিয়া প্রক্রিয়ার অভাব।

Dependabot এখানে দুটি ভূমিকা পালন করে।:

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

কর্মপ্রবাহের জন্য নির্ভরতা গ্রাফ আরেকটি অবমূল্যায়িত বৈশিষ্ট্য. GitHub আপনার ওয়ার্কফ্লো ফাইলগুলিকে ম্যানিফেস্ট হিসেবে বিবেচনা করে এবং আপনাকে দেখাতে পারে:

• আপনি কোন কর্মকাণ্ড এবং পুনঃব্যবহারযোগ্য কর্মপ্রবাহের উপর নির্ভর করেন?
• কোন অ্যাকাউন্ট বা প্রতিষ্ঠান এগুলোর মালিক।
• আপনি কোন সংস্করণ বা SHA গুলিতে পিন করেছেন।

এর ফলে "আমরা এই আপোষিত পদক্ষেপটি কোথায় ব্যবহার করছি?" এর মতো প্রশ্নের উত্তর দেওয়া সহজ হয়। যখন নতুন পরামর্শ বাতিল হবে, এবং ব্যাপক প্রতিকারের পরিকল্পনা করা হবে।

পর্যবেক্ষণ, নিরীক্ষা এবং শাসনব্যবস্থা

নিরাপত্তা কেবল কনফিগারেশনেই শেষ হয় না; সময়ের সাথে সাথে কী ঘটছে তাও আপনার দৃশ্যমানতার প্রয়োজন।. গিটহাব ব্যবহারকারী এবং প্রতিষ্ঠান উভয় স্তরেই অডিট লগ এবং নিরাপত্তা লগ প্রদান করে।

অ্যাকশনের দৃষ্টিকোণ থেকে, ট্র্যাক করার মতো বেশ কিছু বিষয় রয়েছে:

• গোপনীয়তা সম্পর্কিত ঘটনা, যেমন org.update_actions_secret অথবা রিপোজিটরির গোপন পরিবর্তন। এগুলো সংবেদনশীল শংসাপত্র তৈরি, আপডেট বা মুছে ফেলা নির্দেশ করে।
• কর্মপ্রবাহ এবং নিয়ম সেট পরিবর্তন: কে সুরক্ষা নিয়ম পরিবর্তন করেছে, কে স্থাপনার কর্মপ্রবাহ সম্পাদনা করেছে, কে পরিবেশ সুরক্ষা পরিবর্তন করেছে।
• নতুন বা পরিবর্তিত মার্কেটপ্লেস অ্যাকশন এবং গিটহাব অ্যাপস org-এ ইনস্টল করা আছে, বিশেষ করে যেসব প্রতিষ্ঠানে ব্রড রিপোজিটরি বা org স্কোপ দেওয়া হয়েছে।

আপনি OpenSSF থেকে Allstar এর মতো নীতি প্রয়োগকারী অ্যাপগুলির সাথে GitHub-এর নিজস্ব নিয়ন্ত্রণগুলি পরিপূরক করতে পারেন।, যা ক্রমাগত পরীক্ষা করে যে সংগ্রহস্থলগুলি আপনার প্রতিষ্ঠানের নিরাপত্তা বেসলাইন (শাখা সুরক্ষা, কোড স্ক্যানিং সক্ষম, প্রয়োজনীয় পর্যালোচনা ইত্যাদি) মেনে চলে।

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

এই সব একসাথে রাখার অর্থ হল আপনার মূল উৎপাদন পৃষ্ঠের অংশ হিসেবে GitHub Actions-কে ভাবা, শুধু "গ্লু স্ক্রিপ্ট" নয়। সাবধানে স্কোপ করা গোপনীয়তা এবং টোকেন, কঠোর শাখা এবং পরিবেশ সুরক্ষা, তৃতীয় পক্ষের ক্রিয়াকলাপের রক্ষণশীল ব্যবহার, কঠোর রানার এবং CodeQL, Scorecards এবং Dependabot এর মতো সরঞ্জামগুলির সাহায্যে ক্রমাগত পর্যবেক্ষণের মাধ্যমে, আপনি আপনার সংস্থাকে CI/CD এবং সরবরাহ শৃঙ্খল আক্রমণের ক্রমবর্ধমান শ্রেণীর বিরুদ্ধে লড়াইয়ের সুযোগ দেন যা স্পষ্টভাবে GitHub ওয়ার্কফ্লোগুলিকে লক্ষ্য করে।