দীর্ঘমেয়াদী Android নিরাপত্তার জন্য প্রস্তুতকারকের নির্দেশিকা

এই নির্দেশিকাটি Android কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) দ্বারা মূল্যায়ন করা নিরাপত্তা প্যাচ প্রয়োগ করার জন্য Google-এর সুপারিশকৃত সর্বোত্তম অনুশীলনের বর্ণনা করে। এটি অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ OEM সরঞ্জাম (প্রস্তুতকারী) প্রস্তুতকারকদের জন্য তৈরি যা গাড়ি, টিভি, সেট-টপ বক্স এবং হোম অ্যাপ্লায়েন্সের মতো তিন বছরেরও বেশি সময় ধরে সমর্থিত হবে৷ এই নির্দেশিকাটি শেষ ব্যবহারকারীদের জন্য নয় (উদাহরণস্বরূপ, গাড়ির মালিক)।

স্বীকৃতি এবং দাবিত্যাগ

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

প্রতিক্রিয়া

এই নির্দেশিকাটি ব্যাপক হওয়ার উদ্দেশ্যে নয়; অতিরিক্ত সংশোধন পরিকল্পনা করা হয়. manufacturers-guide-android@googlegroups.com-এ প্রতিক্রিয়া জমা দিন।

শব্দকোষ

মেয়াদ সংজ্ঞা
দুদক অ্যান্ড্রয়েড সামঞ্জস্য প্রতিশ্রুতি। পূর্বে Android Anti-Fragmentation Agreement (AFA) নামে পরিচিত।
এওএসপি অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্প
এএসবি অ্যান্ড্রয়েড নিরাপত্তা বুলেটিন
বিএসপি বোর্ড সমর্থন প্যাকেজ
সিডিডি সামঞ্জস্যপূর্ণ সংজ্ঞা নথি
সিটিএস সামঞ্জস্য পরীক্ষা স্যুট
FOTA বাতাসের উপর ফার্মওয়্যার
জিপিএস গ্লোবাল পজিশনিং সিস্টেম
মিসরা মোটর শিল্প সফটওয়্যার নির্ভরযোগ্যতা সমিতি
NIST ন্যাশনাল ইনস্টিটিউট অফ স্ট্যান্ডার্ডস অ্যান্ড টেকনোলজি
ওবিডি অন-বোর্ড ডায়াগনস্টিকস ( OBD-II হল OBD-I-এর তুলনায় সক্ষমতা এবং মানককরণ উভয় ক্ষেত্রেই উন্নতি )
ই এম প্রকৃত যন্ত্রাংশ তৈরিকারী
ওএস অপারেটিং সিস্টেম
এসইআই সফটওয়্যার ইঞ্জিনিয়ারিং ইনস্টিটিউট
SoC চিপে সিস্টেম
এসওপি উত্পাদন শুরু
এসপিএল নিরাপত্তা প্যাচ স্তর
টিপিএমএস টায়ার-চাপ পর্যবেক্ষণ সিস্টেম

অ্যান্ড্রয়েড ওএস সম্পর্কে

অ্যান্ড্রয়েড হল একটি ওপেন সোর্স, লিনাক্স-ভিত্তিক সম্পূর্ণ সফ্টওয়্যার স্ট্যাক যা বিভিন্ন ডিভাইস এবং ফর্ম ফ্যাক্টরের জন্য ডিজাইন করা হয়েছে। 2008 সালে এটির প্রথম প্রকাশের পর থেকে, অ্যান্ড্রয়েড সবচেয়ে জনপ্রিয় অপারেটিং সিস্টেম (OS) হয়ে উঠেছে, যা বিশ্বব্যাপী 1.4+ বিলিয়ন ডিভাইসকে শক্তি প্রদান করে (2016)। মার্চ 2017 পর্যন্ত এই ডিভাইসগুলির প্রায় 67% Android 5.0 (ললিপপ) বা নতুন ব্যবহার করে (আরও সাম্প্রতিক পরিসংখ্যান Android ড্যাশবোর্ডে উপলব্ধ)৷ যদিও বেশিরভাগ ডিভাইস মোবাইল ফোন এবং ট্যাবলেট, অ্যান্ড্রয়েড স্মার্টওয়াচ, টিভি এবং অটোমোটিভ ইন-ভেহিক্যাল ইনফোটেইনমেন্ট (আইভিআই) ডিভাইসে বাড়ছে।

Google Play Store-এ উপলব্ধ Android অ্যাপের সংখ্যা 2.2+ মিলিয়নে পৌঁছেছে (2016)৷ অ্যান্ড্রয়েড অ্যাপ ডেভেলপমেন্ট অ্যান্ড্রয়েড কম্প্যাটিবিলিটি প্রোগ্রাম দ্বারা সমর্থিত, যা সামঞ্জস্যতা ডেফিনিশন ডকুমেন্ট (সিডিডি) এর মাধ্যমে প্রয়োজনীয়তার একটি সেট সংজ্ঞায়িত করে এবং সামঞ্জস্য পরীক্ষা সুইট (সিটিএস) এর মাধ্যমে পরীক্ষার সরঞ্জাম সরবরাহ করে। অ্যান্ড্রয়েড সামঞ্জস্যতা প্রোগ্রামগুলি নিশ্চিত করে যে কোনও অ্যান্ড্রয়েড অ্যাপ যে কোনও অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিভাইসে চলতে পারে যা অ্যাপের জন্য প্রয়োজনীয় বৈশিষ্ট্যগুলিকে সমর্থন করে।

Google নিয়মিতভাবে নতুন OS সংস্করণ, OS নিরাপত্তা আপডেট এবং আবিষ্কৃত দুর্বলতা সম্পর্কে তথ্য প্রকাশ করে। Android OS সমর্থিত পণ্যগুলিতে এই আপডেটগুলির প্রযোজ্যতার জন্য Android নিরাপত্তা বুলেটিন নির্মাতাদের দ্বারা পর্যালোচনা করা উচিত। অ্যান্ড্রয়েড নিরাপত্তা, সামঞ্জস্যতা এবং বিল্ড সিস্টেমের পর্যালোচনার জন্য, নিম্নলিখিতগুলি দেখুন:

সংযুক্ত যানবাহন সম্পর্কে (আদর্শ দীর্ঘজীবী পণ্য)

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

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

ক্ষেত্রের একটি পণ্যের অব্যাহত নিরাপত্তা এবং নিরাপত্তা ভঙ্গি নিশ্চিত করার জন্য প্রস্তুতকারকদের অবশ্যই একটি সক্রিয় পদ্ধতি অবলম্বন করতে হবে। সংক্ষেপে, নির্মাতাদের অবশ্যই পণ্যের পরিচিত নিরাপত্তা দুর্বলতা সম্পর্কে সচেতন হতে হবে এবং তাদের মোকাবেলা করার জন্য একটি ঝুঁকি-ভিত্তিক পদ্ধতি অবলম্বন করতে হবে।

দীর্ঘমেয়াদী নিরাপত্তা নিশ্চিত করুন

একটি সংযুক্ত গাড়িতে প্রায়শই এক বা একাধিক ইলেকট্রনিক কন্ট্রোল ইউনিট (ECUs) থাকে যাতে একাধিক সফ্টওয়্যার উপাদান যেমন OS, লাইব্রেরি, ইউটিলিটি ইত্যাদি অন্তর্ভুক্ত থাকে৷ নির্মাতাদের উচিত এই জাতীয় উপাদানগুলিকে ট্র্যাক করা এবং সক্রিয় বিশ্লেষণের মাধ্যমে পরিচিত প্রকাশিত দুর্বলতাগুলি সনাক্ত করা, যার মধ্যে রয়েছে:

  • কমন ভালনারেবিলিটিস অ্যান্ড এক্সপোজারস (CVE) ডাটাবেসের বিরুদ্ধে নিয়মিতভাবে পণ্যটির মূল্যায়ন করা।
  • পণ্য-সম্পর্কিত নিরাপত্তা ত্রুটির জন্য বুদ্ধিমত্তা সংগ্রহ।
  • নিরাপত্তা পরীক্ষা।
  • সক্রিয়ভাবে অ্যান্ড্রয়েড নিরাপত্তা বুলেটিন বিশ্লেষণ।

উদাহরণ OS এবং নিরাপত্তা প্যাচ আপডেট (Android চলমান IVI):

চিত্র 1. নমুনা প্রধান OS এবং নিরাপত্তা আপডেট রোলআউট গাড়ির জীবনকালের উপর।

# ধাপ কার্যক্রম

①

 উন্নয়ন শাখা নির্মাতা অ্যান্ড্রয়েড (অ্যান্ড্রয়েড এক্স) এর একটি সংস্করণ নির্বাচন করে। এই উদাহরণে, "Android X" প্রাথমিক স্টার্ট অফ প্রোডাকশন (SOP) এর দুই বছর আগে গাড়িতে কী পাঠানো হবে তার ভিত্তি হয়ে ওঠে।
② প্রাথমিক লঞ্চ Android X পণ্যটিতে পাঠানোর প্রথম OS সংস্করণ হওয়ার কয়েক মাস আগে, নিরাপত্তা আপডেটগুলি Android সিকিউরিটি বুলেটিন (ASBs) এবং সম্ভাব্য অন্যান্য উত্সগুলি থেকে নেওয়া হয় যা নির্মাতার দ্বারা মূল্যবান বলে বিবেচিত হয়। y2 = অ্যান্ড্রয়েডের X সংস্করণের জন্য দ্বিতীয় নিরাপত্তা বুলেটিন, নির্মাতার দ্বারা Android X-এ প্রয়োগ করা হয়েছে (ব্যাকপোর্ট করা হয়েছে)

এই উদাহরণে, নির্মাতা আরও সাম্প্রতিক Android X+1 বার্ষিক রিলিজ পাঠানো না করার সিদ্ধান্ত নিয়েছে। সাম্প্রতিকতম রিলিজ পাঠানোর কারণগুলির মধ্যে রয়েছে নতুন বৈশিষ্ট্য যোগ করা, নতুন নিরাপত্তা দুর্বলতাগুলিকে মোকাবেলা করা এবং/অথবা Google বা তৃতীয় পক্ষের পরিষেবাগুলি যা নতুন Android সংস্করণের প্রয়োজন। সাম্প্রতিক প্রকাশের সাথে শিপিংয়ের বিরুদ্ধে কারণগুলি হল সমস্ত নিয়ন্ত্রক এবং সার্টিফিকেশন প্রয়োজনীয়তাগুলির সাথে সম্মতি সহ পরিবর্তনগুলিকে সংহত, পরীক্ষা এবং যাচাই করার জন্য প্রয়োজনীয় যানবাহন বিকাশ এবং লঞ্চ প্রক্রিয়ার অন্তর্নিহিত সময়ের অভাব।

③ সম্পূর্ণ OS আপডেট SOP-এর পরে, প্রস্তুতকারক Android X+2 OS আপডেট প্রকাশ করে, যা প্রাথমিক পণ্যের (Android X0) জন্য ব্যবহৃত সংস্করণের পরে দুটি Android রিলিজ। ASB নিরাপত্তা আপডেটগুলি API স্তরের জন্য উপলব্ধ (জাহাজের তারিখ অনুসারে), তাই SOP-এর প্রায় 1.25 বছর পরে আপডেটটি X+2.y0 হিসাবে বেরিয়ে যায়। এই OS আপডেট ফিল্ড করা পণ্যের সাথে সামঞ্জস্যপূর্ণ হতে পারে বা নাও হতে পারে। যদি এটি হয়, স্থাপন করা যানবাহন আপডেট করার জন্য একটি পরিকল্পনা তৈরি করা যেতে পারে।

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

④ নিরাপত্তা আপডেট গাড়ির উৎপাদন আয়ুষ্কালের দুই বছর পর, নির্মাতা অ্যান্ড্রয়েড X+2 OS প্যাচ করে। এই সিদ্ধান্তটি প্রস্তুতকারকের ঝুঁকি মূল্যায়নের উপর ভিত্তি করে। প্রস্তুতকারক আপডেটের ভিত্তিতে X+2 প্রকাশের জন্য তৃতীয় ASB নিরাপত্তা আপডেট বেছে নেয়। নিরাপত্তা আপডেট প্রাপ্ত পণ্যগুলি এখন (X+2.y3) OS + Android নিরাপত্তা প্যাচ স্তরে রয়েছে৷

যদিও নির্মাতারা যেকোন পৃথক ASB থেকে পৃথক নিরাপত্তা প্যাচ নির্বাচন করতে পারেন, বুলেটিনের সাথে যুক্ত Android নিরাপত্তা প্যাচ স্তর (SPL) ব্যবহার করার জন্য তাদের বুলেটিনে প্রয়োজনীয় সমস্ত সমস্যা সমাধান করতে হবে (উদাহরণস্বরূপ, 2017-02-05)। সমর্থিত পণ্যের জন্য ব্যাকপোর্ট এবং নিরাপত্তা প্রকাশের দায়িত্ব প্রস্তুতকারকের।

⑤ সম্পূর্ণ OS আপডেট ধাপ 3 (সম্পূর্ণ OS আপডেট) এর পুনরাবৃত্তি, দ্বিতীয় পূর্ণ OS আপডেট পণ্যটিকে Android X+4 পর্যন্ত নিয়ে আসে, গাড়ির উৎপাদন আয়ুষ্কাল তিন বছর। প্রস্তুতকারক এখন একটি সাম্প্রতিক অ্যান্ড্রয়েড সংস্করণের নতুন হার্ডওয়্যার প্রয়োজনীয়তাগুলির সাথে পণ্যের হার্ডওয়্যারের বিপরীতে ভারসাম্য বজায় রাখছে এবং একটি আপডেট হওয়া অ্যান্ড্রয়েড ওএস থেকে ব্যবহারকারীর সুবিধা রয়েছে৷ নির্মাতা নিরাপত্তা আপডেট ছাড়াই একটি আপডেট প্রকাশ করে, তাই পণ্যটি এখন (X+4.y0) OS + Android নিরাপত্তা প্যাচ স্তরে রয়েছে।

এই উদাহরণে, হার্ডওয়্যার সীমাবদ্ধতার কারণে, X+4 হল Android এর শেষ প্রধান সংস্করণ যা এই পণ্যের জন্য প্রদান করা হবে, যদিও গাড়ির জন্য প্রত্যাশিত জীবনকালের 6+ বছরের জন্য এখনও নিরাপত্তা সমর্থন প্রয়োজন৷

⑥ নিরাপত্তা আপডেট ধাপ 4 এর পুনরাবৃত্তি (নিরাপত্তা আপডেট)। অ্যান্ড্রয়েড (X+6) এর অনেক পরবর্তী সংস্করণ থেকে ASB নিরাপত্তা আপডেট নেওয়া এবং সেই আপডেটগুলির কিছু বা সমস্ত Android X+4-এ পোর্ট করার কাজটি প্রস্তুতকারকের রয়েছে। আপডেটগুলি একত্রিত করা, সংহত করা এবং সম্পাদন করা (বা তৃতীয় পক্ষের সাথে চুক্তি করা) প্রস্তুতকারকের দায়িত্ব৷ এছাড়াও, প্রস্তুতকারকের সচেতন হওয়া উচিত যে অ্যান্ড্রয়েডের যে সংস্করণগুলি আর সমর্থিত নয় সেগুলির নিরাপত্তা সংক্রান্ত সমস্যাগুলি ASB-তে অন্তর্ভুক্ত নয়৷
⑦ নিরাপত্তা আপডেট গাড়ির উৎপাদন জীবনচক্রের আট বছর, ধাপ 5-এ শেষ OS আপডেটের পর থেকে চারটি অ্যান্ড্রয়েড রিলিজ (সম্পূর্ণ OS আপডেট), এবং Android X নির্দিষ্ট করার দশ বছর পর থেকে, নিরাপত্তা প্যাচগুলি কিউরেট করা এবং ব্যাকপোর্ট করার ভার সম্পূর্ণভাবে প্রস্তুতকারকের উপর API স্তরের পাবলিক রিলিজ থেকে তিন বছরের বেশি পুরানো সংস্করণ।

নিরাপত্তা সেরা অনুশীলন

নিরাপত্তা সমঝোতাকে আরও কঠিন করার জন্য, Google নিরাপত্তা এবং সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের জন্য সাধারণভাবে গৃহীত সর্বোত্তম অনুশীলনগুলি ব্যবহার করার সুপারিশ করে এবং নিয়োগ করে, যেমনটি নিরাপত্তা বাস্তবায়নে বর্ণিত হয়েছে৷

নিরাপত্তা নির্দেশিকা

নিরাপত্তার জন্য প্রস্তাবিত অনুশীলন অন্তর্ভুক্ত:

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

সফ্টওয়্যার উন্নয়ন নির্দেশিকা

সিস্টেমের জীবনচক্রের জন্য নিরাপদ সফ্টওয়্যার বিকাশের জন্য প্রস্তাবিত অনুশীলনগুলির মধ্যে রয়েছে:

  • সম্পদ, হুমকি, এবং সম্ভাব্য প্রশমন র্যাঙ্ক এবং সনাক্ত করতে হুমকি মডেলিং সম্পাদন করুন।
  • সুরক্ষিত এবং সাউন্ড ডিজাইন নিশ্চিত করতে আর্কিটেকচার/ডিজাইন পর্যালোচনা করুন।
  • যত তাড়াতাড়ি সম্ভব অ্যান্টি-প্যাটার্ন এবং বাগ সনাক্ত করতে নিয়মিত কোড পর্যালোচনা করুন।
  • ডিজাইন, বাস্তবায়ন, এবং হাই-কোড কভারেজ ইউনিট পরীক্ষা চালান, সহ:
    • কার্যকরী পরীক্ষা (নেতিবাচক পরীক্ষার ক্ষেত্রে সহ)
    • নিয়মিত রিগ্রেশন টেস্টিং (স্থির বাগগুলি পুনরুত্থিত না হয় তা নিশ্চিত করতে)
    • ফাজ টেস্টিং (ইউনিট টেস্ট স্যুটের অংশ হিসেবে)
  • সম্ভাব্য সমস্যা চিহ্নিত করতে স্ট্যাটিক সোর্স কোড বিশ্লেষণ টুল (স্ক্যান-বিল্ড, লিন্ট, ইত্যাদি) ব্যবহার করুন।
  • সিস্টেম ডেভেলপমেন্টের সময় সম্ভাব্য সমস্যা শনাক্ত করতে এবং প্রশমিত করতে ডায়নামিক সোর্স কোড বিশ্লেষণ টুল ব্যবহার করুন, যেমন AddressSanitizer, UndefinedBehaviorSanitizer এবং FORTIFY_SOURCE (নেটিভ উপাদানের জন্য)।
  • সফ্টওয়্যার সোর্স কোড এবং রিলিজ কনফিগারেশন/সংস্করণের জন্য একটি পরিচালনার কৌশল রাখুন।
  • সফ্টওয়্যার প্যাচ তৈরি এবং স্থাপনের জন্য একটি প্যাচ পরিচালনার কৌশল রাখুন।

নিরাপত্তা ব্যাকপোর্ট নীতি

Google বর্তমানে API স্তরের পাবলিক রিলিজ থেকে তিন (3) বছরের জন্য আবিষ্কৃত এবং রিপোর্ট করা নিরাপত্তা দুর্বলতার নিরাপত্তা ব্যাকপোর্টের জন্য সক্রিয় সমর্থন প্রদান করে। সক্রিয় সমর্থন নিম্নলিখিত গঠিত:

  1. দুর্বলতা রিপোর্ট গ্রহণ এবং তদন্ত.
  2. নিরাপত্তা আপডেট তৈরি করুন, পরীক্ষা করুন এবং প্রকাশ করুন।
  3. নিরাপত্তা আপডেট এবং নিরাপত্তা বুলেটিন বিশদগুলির পুনরাবৃত্তিমূলক রিলিজ প্রদান করুন।
  4. প্রতিষ্ঠিত নির্দেশিকা অনুযায়ী তীব্রতা মূল্যায়ন সঞ্চালন.

API স্তরের সর্বজনীন প্রকাশের তারিখ থেকে তিন বছর পর, Google নিম্নলিখিত নির্দেশিকাগুলির সুপারিশ করে:

  • API রিলিজ থেকে তিন বছরের বেশি পুরানো OS নিরাপত্তা আপডেটের জন্য ব্যাকপোর্ট সমর্থনের জন্য একটি তৃতীয়-পক্ষ (যেমন SoC ভেন্ডর বা কার্নেল প্রদানকারী) ব্যবহার করুন।
  • সর্বজনীনভাবে প্রদত্ত ASB ব্যবহার করে কোড পর্যালোচনা করতে তৃতীয় পক্ষ ব্যবহার করুন। যদিও ASBs বর্তমানে সমর্থিত সংস্করণের জন্য দুর্বলতা সনাক্ত করে, একজন প্রস্তুতকারক পূর্ববর্তী সংস্করণগুলির সাথে নতুন প্রকাশিত আপডেটগুলির তুলনা করতে প্রদত্ত তথ্য ব্যবহার করতে পারে। এই ডেটা প্রভাব বিশ্লেষণ করতে ব্যবহার করা যেতে পারে এবং API রিলিজ থেকে তিন বছরের বেশি পুরানো OS সংস্করণগুলির জন্য সম্ভাব্য একই প্যাচ তৈরি করতে পারে।
  • উপযুক্ত হলে, Android ওপেন সোর্স প্রজেক্টে (AOSP) নিরাপত্তা আপডেট আপলোড করুন।
  • বিক্রেতা-নির্দিষ্ট কোডের (উদাহরণস্বরূপ, মালিকানাধীন ডিভাইস-নির্দিষ্ট কোড) জন্য প্রস্তুতকারকের নিরাপত্তা আপডেট পরিচালনার সমন্বয় করতে হবে।
  • প্রস্তুতকারকের এনডিএ অ্যান্ড্রয়েড সিকিউরিটি বুলেটিন পার্টনার প্রিভিউ নোটিফিকেশন গ্রুপে যোগদান করা উচিত (ডেভেলপার NDA-এর মতো আইনি চুক্তিতে স্বাক্ষর করা প্রয়োজন)। বুলেটিন অন্তর্ভুক্ত করা উচিত:
    • ঘোষণা
    • CVE এবং তীব্রতা সহ প্যাচ স্তর অনুসারে সমস্যার সারাংশ
    • যেখানে উপযুক্ত সেখানে দুর্বলতার বিবরণ

অতিরিক্ত রেফারেন্স

নিরাপদ কোডিং এবং সফ্টওয়্যার উন্নয়ন অনুশীলনের নির্দেশাবলীর জন্য, নিম্নলিখিতগুলি পড়ুন:

Google নিম্নলিখিত প্রস্তাবিত অনুশীলনগুলি ব্যবহার করতে উত্সাহিত করে৷

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

প্রস্তাবিত নির্দেশিকা অন্তর্ভুক্ত:

  • যানবাহন বিকাশের প্রক্রিয়ার অন্তর্নিহিত দীর্ঘ বিকাশের লিড সময়ের কারণে, নির্মাতাদের OS সংস্করণ n-2 বা তার বেশির সাথে চালু করতে হতে পারে।
  • একটি ওভার-দ্য-এয়ার (OTA) প্রচারাভিযানের সাথে প্রতিটি প্রকাশিত Android OS সংস্করণের জন্য Android সামঞ্জস্যের সাথে সামঞ্জস্য বজায় রাখুন।
  • দ্রুত, গ্রাহক-বান্ধব আপডেটের জন্য সক্ষম পণ্য Android ফার্মওয়্যার-ওভার-দ্য-এয়ার (FOTA) প্রয়োগ করুন৷ পণ্য এবং আইটি ব্যাকঅফিসের মধ্যে কোড সাইনিং এবং TLS সংযোগের মতো নিরাপত্তার সর্বোত্তম অনুশীলনগুলি ব্যবহার করে FOTA করা উচিত।
  • Android সিকিউরিটি টিমের কাছে স্বাধীনভাবে চিহ্নিত Android নিরাপত্তা দুর্বলতাগুলি জমা দিন ৷

দ্রষ্টব্য: Google অ্যান্ড্রয়েড সিকিউরিটি বুলেটিনে ডিভাইসের ধরন বা শিল্প-নির্দিষ্ট বিজ্ঞপ্তিগুলি বিবেচনা করেছে৷ যাইহোক, যেহেতু Google একটি প্রদত্ত ডিভাইসের জন্য কার্নেল, ড্রাইভার বা চিপসেট জানে না (যানবাহন, টিভি, পরিধানযোগ্য, ফোন, ইত্যাদি), Google-এর কাছে কোনও ডিভাইসের প্রকারের সাথে কোনও প্রদত্ত সুরক্ষা সমস্যা লেবেল করার কোনও নির্ধারক উপায় নেই .

প্রস্তুতকারকের উচিত পণ্য চক্রের উন্নতির সময় ব্যবহার করা সংস্করণের জন্য সর্বশেষ OS সংস্করণ বা সুরক্ষা আপডেটগুলি ব্যবহার করার জন্য সর্বাত্মক প্রচেষ্টা করা। আপডেটগুলি পুনরাবৃত্ত পর্যায়ক্রমিক পণ্য আপডেটের সময় বা গুণমান এবং/অথবা অন্যান্য সমস্যার সমাধান করার জন্য হটফিক্সের জন্য সঞ্চালিত হতে পারে। প্রস্তাবিত অনুশীলন অন্তর্ভুক্ত:

  • ড্রাইভার, কার্নেল এবং প্রোটোকল আপডেটের জন্য একটি পরিকল্পনা তৈরি করুন।
  • স্থাপন করা যানবাহন আপডেট প্রদানের জন্য একটি শিল্প উপযুক্ত পদ্ধতি ব্যবহার করুন.

সামঞ্জস্যপূর্ণ সংজ্ঞা নথি (CDD)

কম্প্যাটিবিলিটি ডেফিনিশন ডকুমেন্ট (CDD) Android-এর সাথে সামঞ্জস্যপূর্ণ বলে বিবেচিত ডিভাইসের প্রয়োজনীয়তা বর্ণনা করে। CDD সর্বজনীন এবং সবার জন্য উপলব্ধ; আপনি source.android.com থেকে Android 1.6 থেকে সর্বশেষ সংস্করণে CDD সংস্করণ ডাউনলোড করতে পারেন।

একটি পণ্যের জন্য এই প্রয়োজনীয়তাগুলি সন্তুষ্ট করার জন্য নিম্নলিখিত মৌলিক পদক্ষেপগুলি জড়িত:

  1. অংশীদার Google এর সাথে Android সামঞ্জস্যপূর্ণ প্রতিশ্রুতি (ACC) স্বাক্ষর করে৷ একজন টেকনিক্যাল সলিউশন কনসালটেন্ট (TSC) কে তারপর গাইড হিসেবে নিয়োগ করা হয়।
  2. অংশীদার পণ্যটির Android OS সংস্করণের জন্য CDD পর্যালোচনা সম্পূর্ণ করে৷
  3. অ্যান্ড্রয়েড সামঞ্জস্যের জন্য ফলাফল গ্রহণযোগ্য না হওয়া পর্যন্ত অংশীদার CTS ফলাফল চালায় এবং জমা দেয় (নীচে বর্ণিত)।

সামঞ্জস্য পরীক্ষা স্যুট (CTS)

কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) টেস্টিং টুলটি যাচাই করে যে একটি পণ্য বাস্তবায়ন Android-এর সাথে সামঞ্জস্যপূর্ণ এবং সর্বশেষ নিরাপত্তা প্যাচ অন্তর্ভুক্ত করা হয়েছে। CTS সর্বজনীন, ওপেন সোর্স এবং সবার জন্য উপলব্ধ; আপনি source.android.com থেকে Android 1.6 থেকে সর্বশেষ সংস্করণে CTS সংস্করণ ডাউনলোড করতে পারেন।

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

দ্রষ্টব্য: যে অংশীদাররা অন্যান্য চুক্তিতে স্বাক্ষর করে, যেমন Google মোবাইল পরিষেবা (GMS) , তাদের অন্যান্য প্রয়োজনীয়তা পূরণ করতে হতে পারে৷

CTS কর্মপ্রবাহ

CTS কর্মপ্রবাহের মধ্যে রয়েছে পরীক্ষার পরিবেশ সেট আপ করা, পরীক্ষা চালানো, ফলাফল ব্যাখ্যা করা এবং CTS সোর্স কোড বোঝা। নিম্নলিখিত নির্দেশিকাগুলি CTS ব্যবহারকারীদের (উদাহরণস্বরূপ, বিকাশকারী, নির্মাতাদের) কার্যকরভাবে এবং দক্ষতার সাথে CTS ব্যবহার করতে সহায়তা করার উদ্দেশ্যে।

  • ঘন ঘন পরীক্ষা চালান । CTS একটি স্বয়ংক্রিয় সরঞ্জাম হিসাবে ডিজাইন করা হয়েছে যা আপনার বিল্ড সিস্টেমে সংহত করে। ঘন ঘন CTS চালানো আপনাকে সফ্টওয়্যার অবক্ষয় বা রিগ্রেশন ঘটলে দ্রুত এবং তাড়াতাড়ি ত্রুটি খুঁজে পেতে সাহায্য করতে পারে।
  • CTS সোর্স কোড ডাউনলোড করুন এবং পরীক্ষা করুন । সম্পূর্ণ CTS সোর্স কোড হল ওপেন সোর্স সফ্টওয়্যার যা যেকেউ ডাউনলোড এবং ব্যবহার করতে পারে (ডাউনলোড করা সোর্স কোড সম্পূর্ণরূপে তৈরি করা যায় এবং চালানো যায়)। ডিভাইসে কোনো পরীক্ষা ব্যর্থ হলে, সোর্স কোডের প্রাসঙ্গিক বিভাগটি পরীক্ষা করা আপনাকে কেন শনাক্ত করতে সাহায্য করতে পারে।
  • সর্বশেষ CTS পান । নতুন অ্যান্ড্রয়েড রিলিজ বাগ ফিক্স, উন্নতি এবং নতুন পরীক্ষা সহ CTS আপডেট করতে পারে। ঘন ঘন CTS ডাউনলোড চেক করুন এবং প্রয়োজনে আপনার CTS প্রোগ্রাম আপডেট করুন। উৎপাদনকারী এবং Google পণ্য লঞ্চের জন্য পাস করার জন্য CTS সংস্করণে সম্মত হবে কারণ CTS রিফ্রেশ হওয়ার সময় পণ্যটিকে অবশ্যই কিছু সময়ে হিমায়িত করতে হবে।

CTS পাস

একটি Android সামঞ্জস্যপূর্ণ পণ্যের জন্য, Google নিশ্চিত করে যে ডিভাইসের CTS এবং CTS যাচাইকারী রিপোর্ট পরীক্ষার ফলাফল গ্রহণযোগ্য। নীতিগতভাবে, সমস্ত পরীক্ষা অবশ্যই পাস করতে হবে। যাইহোক, ডিভাইসটি অ্যান্ড্রয়েড সামঞ্জস্যের প্রয়োজনীয়তাগুলির সাথে সম্মত না হওয়া ছাড়া অন্য কারণগুলির জন্য ব্যর্থ হওয়া একটি পরীক্ষা Google দ্বারা পর্যালোচনা করা হবে৷ এই প্রক্রিয়া চলাকালীন:

  1. প্রস্তুতকারক যুক্তি প্রমাণ করার জন্য প্রস্তাবিত CTS প্যাচ, প্যাচ যাচাইকরণ এবং ন্যায্যতা দিয়ে Google-কে প্রদান করে।
  2. Google জমা দেওয়া উপাদান পরীক্ষা করে, এবং গ্রহণ করা হলে, প্রাসঙ্গিক CTS পরীক্ষাগুলি আপডেট করে যাতে ডিভাইসটি CTS-এর পরবর্তী সংশোধনে পাস করতে পারে।

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

CTS পরীক্ষা সংশোধনের পর্যালোচনার জন্য উন্মুক্ত থাকে। উদাহরণস্বরূপ, অ্যান্ড্রয়েড 4.4 ফিক্সগুলি গ্রহণ করে চলেছে (দেখুন https://android-review.googlesource.com/#/c/273371/ )।

প্রায়শই জিজ্ঞাসিত প্রশ্ন (FAQs)

প্রশ্ন: Android এর একটি নির্দিষ্ট বাস্তবায়নে নিরাপত্তা আপডেট প্রয়োগ করার জন্য কে দায়ী?

উত্তর: ডিভাইসটি সরাসরি সরবরাহকারী নির্মাতা দায়ী। এই সত্তাটি Google নয় , যেটি AOSP-তে নিরাপত্তা আপডেট প্রকাশ করে এবং কোনো নির্দিষ্ট ডিভাইসের (যেমন গাড়ির) জন্য নয়।

প্রশ্ন: গুগল কীভাবে অ্যান্ড্রয়েডে নিরাপত্তা সমস্যাগুলি পরিচালনা করে?

উত্তর: Google ক্রমাগত সমস্যাগুলির তদন্ত করে এবং সম্ভাব্য সমাধানগুলি বিকাশ করে, যা নিয়মিত নিরাপত্তা আপডেট প্রক্রিয়ার অংশ হিসাবে Google সমস্ত সমর্থিত API স্তরগুলিতে উপলব্ধ করে৷ 2015 সালের অগাস্ট থেকে, Google বুলেটিন প্রকাশের একটি নিয়মিত ক্যাডেন্স এবং source.android.com- এর আপডেটের লিঙ্ক বজায় রেখেছে; Google প্রধান ওএস রিলিজের অংশ হিসেবে নিরাপত্তা আপডেটও প্রকাশ করে। নিরাপত্তা ব্যাকপোর্ট নীতিও দেখুন।

প্রশ্ন: যদি একটি প্রস্তুতকারক একটি ASB থেকে সমস্ত AOSP প্যাচ একত্রিত করে কিন্তু একই বুলেটিনে উল্লিখিত BSP বিক্রেতার প্যাচগুলিকে একত্রিত না করে, তবে এটি কি এখনও নিরাপত্তা স্তর বাড়াতে পারে (উদাহরণস্বরূপ, প্ল্যাটফর্ম/বিল্ডে সংশ্লিষ্ট প্যাচ প্রয়োগ করুন)?

উত্তর: একটি Android নিরাপত্তা প্যাচ স্তর (SPL) ঘোষণা করতে, একজন নির্মাতাকে অবশ্যই Android নিরাপত্তা বুলেটিনে প্রকাশিত সমস্ত প্রয়োজনীয় সমস্যার সমাধান করতে হবে ( পূর্বের বুলেটিনগুলি সহ ) এবং একটি নির্দিষ্ট Android SPL-এ ম্যাপ করা হয়েছে৷ উদাহরণস্বরূপ, মার্চ 2017 সিকিউরিটি বুলেটিন (2017-03-01 SPL) ব্যবহার করে একজন প্রস্তুতকারক সেই SPL-এর জন্য মার্চ 2017 বুলেটিনে নথিভুক্ত সমস্ত প্রয়োজনীয় সমস্যার সমাধান করেছেন এবং সমস্ত পূর্ববর্তী Android সিকিউরিটি বুলেটিনগুলির জন্য ডিভাইস-নির্দিষ্ট আপডেট সহ সমস্ত পূর্ববর্তী আপডেটগুলি সহ 2017-02-05 SPL-এর সাথে যুক্ত ডিভাইস-নির্দিষ্ট আপডেট।

প্রশ্ন: যখন প্রস্তুতকারক BSP ভেন্ডর দ্বারা প্রদত্ত নিরাপত্তা আপডেটের সাথে একমত না হন বা যখন ASB দ্বারা বাধ্যতামূলক নিরাপত্তা আপডেটগুলি বিক্রেতাদের দ্বারা প্রদান করা হয় না তখন কি হবে?

উত্তর: একটি ASB নিরাপত্তা দুর্বলতা বর্ণনা করে (CVE-এর একটি তালিকা দ্বারা গণনা করা হয়েছে) এবং প্রায়শই মিলে যাওয়া নিরাপত্তা পরীক্ষা প্রদান করে। লক্ষ্য হল তালিকাভুক্ত দুর্বলতাগুলি আর কোনও ডিভাইসে পুনরুত্পাদন করা যাবে না এবং ডিভাইসটি সংশ্লিষ্ট নিরাপত্তা পরীক্ষায় উত্তীর্ণ হতে পারে তা নিশ্চিত করা। যেমন, সমস্যাটি Google বা তৃতীয় পক্ষের বিক্রেতার দ্বারা প্রদত্ত একটি সুরক্ষা আপডেট নেওয়ার বিষয়ে নয়, তবে নির্মাতার দ্বারা প্রমাণ করা হচ্ছে যে ডিভাইসটি ASB-এর CVE-এর তালিকার জন্য ঝুঁকিপূর্ণ নয়। প্রস্তুতকারক প্রদত্ত সুরক্ষা আপডেটগুলি ব্যবহার করার জন্য বিনামূল্যে বা, যদি তাদের ডিভাইসের জন্য আরও উপযুক্ত এমন কোনও পরিবর্তন থাকে তবে পরিবর্তে সেই পরিবর্তনটি ব্যবহার করুন৷

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

ASB-তে সমস্ত সমস্যার সমাধান নিশ্চিত করতে আমরা সমস্ত SoC অংশীদারদের সাথে কাজ করার সময়, আমরা সুপারিশ করি যে নির্মাতারা একটি ডিভাইসের জীবনচক্রের জন্য তাদের SoC বিক্রেতাদের সাথে একটি পরিষেবা চুক্তি সুরক্ষিত করুন। SoCs কাঙ্খিত সময়ের আগে একটি চিপসেট পরিষেবা দেওয়া বন্ধ করতে পারে, তাই ডিভাইস চিপসেট নির্বাচনের আগে চুক্তি স্থাপন করা ডিভাইস লঞ্চ প্রক্রিয়ার একটি গুরুত্বপূর্ণ অংশ।

অবশেষে, যে ক্ষেত্রে ASB-তে নথিভুক্ত কোনও সমস্যার জন্য সরাসরি অর্জন করা বা স্বাধীনভাবে একটি সমাধান তৈরি করা অসম্ভব, সেখানে একজন নির্মাতা পূর্বের Android SPL বজায় রাখতে পারে এবং এখনও বিল্ডে নতুন উপলব্ধ ফিক্স যোগ করতে পারে। যাইহোক, এই অভ্যাসটি শেষ পর্যন্ত বিল্ড সার্টিফিকেশন নিয়ে সমস্যার দিকে নিয়ে যাবে (যেমন অ্যান্ড্রয়েড নিশ্চিত করে যে প্রত্যয়িত ডিভাইসগুলিতে সর্বশেষ নিরাপত্তা প্যাচ স্তর উপলব্ধ রয়েছে)। Google এই অভ্যাস এড়াতে আপনার SoC এর সাথে আগে থেকে কাজ করার পরামর্শ দেয়।

প্রশ্ন: প্রস্তুতকারক যদি নির্ধারণ করেন যে একটি ASB আইটেম তাদের পণ্যের জন্য প্রযোজ্য নয়, তাহলে কি Google এর অন্যান্য প্রয়োজনীয়তা পূরণ করতে বা CTS পাস করার জন্য আইটেমটিকে প্রয়োগ বা প্যাচ করতে হবে?

উত্তর: অ্যান্ড্রয়েড সিকিউরিটি প্যাচ লেভেল (এসপিএল) ঘোষণা করার জন্য আমাদের প্যাচ নেওয়ার প্রয়োজন নেই; আমাদের প্রয়োজন যে প্রস্তুতকারক প্রমাণ করে যে তাদের বিল্ড সমস্যাটির জন্য ঝুঁকিপূর্ণ নয়।

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

এটি একটি প্রস্তুতকারকের চেয়ে মৌলিকভাবে ভিন্ন, উদাহরণস্বরূপ, শুধুমাত্র সমালোচনামূলক প্যাচগুলি ঠিক করতে, অন্য প্রযোজ্য প্যাচগুলি গ্রহণ না করে যা একটি নিরাপত্তা পরীক্ষা ব্যর্থ হতে পারে৷ এই ক্ষেত্রে SPL পূরণ হয়নি বলে ধরে নেওয়া হয়।