নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য আপনাকে অ্যাপ কোড পরিবর্তন না করেই একটি নিরাপদ, ঘোষণামূলক কনফিগারেশন ফাইলে আপনার অ্যাপের নেটওয়ার্ক নিরাপত্তা সেটিংস কাস্টমাইজ করতে দেয়। এই সেটিংস নির্দিষ্ট ডোমেন এবং একটি নির্দিষ্ট অ্যাপের জন্য কনফিগার করা যেতে পারে। এই বৈশিষ্ট্যের মূল ক্ষমতা হল:
- কাস্টম ট্রাস্ট অ্যাঙ্কর: একটি অ্যাপের সুরক্ষিত সংযোগের জন্য কোন সার্টিফিকেট অথরিটি (CA) বিশ্বস্ত তা কাস্টমাইজ করুন। উদাহরণস্বরূপ, নির্দিষ্ট স্ব-স্বাক্ষরিত শংসাপত্রগুলিতে বিশ্বাস করা বা অ্যাপটি বিশ্বাস করে এমন পাবলিক CA-এর সেটকে সীমাবদ্ধ করা৷
- ডিবাগ-অনলি ওভাররাইড: ইনস্টল করা বেসে অতিরিক্ত ঝুঁকি ছাড়াই একটি অ্যাপে নিরাপদে সুরক্ষিত সংযোগ ডিবাগ করুন।
- ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট: ক্লিয়ারটেক্সট (অএনক্রিপ্ট করা) ট্র্যাফিকের দুর্ঘটনাজনিত ব্যবহার থেকে অ্যাপগুলিকে রক্ষা করুন।
- শংসাপত্রের স্বচ্ছতা অপ্ট-ইন: প্রমাণিতভাবে লগ করা শংসাপত্রগুলি ব্যবহার করতে একটি অ্যাপের সুরক্ষিত সংযোগগুলিকে সীমাবদ্ধ করুন৷
- শংসাপত্র পিনিং: নির্দিষ্ট শংসাপত্রের সাথে একটি অ্যাপের সুরক্ষিত সংযোগ সীমাবদ্ধ করুন।
একটি নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল যোগ করুন
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্যটি একটি XML ফাইল ব্যবহার করে যেখানে আপনি আপনার অ্যাপের জন্য সেটিংস নির্দিষ্ট করেন। এই ফাইলটি নির্দেশ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে একটি এন্ট্রি অন্তর্ভুক্ত করতে হবে৷ একটি ম্যানিফেস্ট থেকে নিম্নলিখিত কোড উদ্ধৃতি প্রদর্শন করে কিভাবে এই এন্ট্রি তৈরি করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <manifest ... > <application android:networkSecurityConfig="@xml/network_security_config" ... > ... </application> </manifest>
বিশ্বস্ত CA কাস্টমাইজ করুন
আপনি প্ল্যাটফর্ম ডিফল্টের পরিবর্তে আপনার অ্যাপটি CA-এর একটি কাস্টম সেট বিশ্বাস করতে চাইতে পারেন। এর জন্য সবচেয়ে সাধারণ কারণগুলি হল:
- একটি কাস্টম CA সহ একটি হোস্টের সাথে সংযোগ করা, যেমন একটি CA যা স্ব-স্বাক্ষরিত বা একটি কোম্পানির মধ্যে অভ্যন্তরীণভাবে জারি করা হয়৷
- প্রতিটি প্রি-ইনস্টল করা CA-এর পরিবর্তে শুধুমাত্র আপনার বিশ্বাসযোগ্য CA-এর মধ্যে CA-এর সেট সীমাবদ্ধ করা।
- সিস্টেমে অন্তর্ভুক্ত নয় অতিরিক্ত CA-কে বিশ্বাস করা।
ডিফল্টরূপে, সমস্ত অ্যাপ থেকে সুরক্ষিত সংযোগগুলি (TLS এবং HTTPS-এর মতো প্রোটোকল ব্যবহার করে) আগে থেকে ইনস্টল করা সিস্টেম CA-কে বিশ্বাস করে এবং Android 6.0 (API লেভেল 23) এবং নিম্নতর অ্যাপ্লিকেশানগুলিকে লক্ষ্য করে ডিফল্টভাবে ব্যবহারকারী-যুক্ত CA স্টোরকেও বিশ্বাস করে৷ আপনি base-config
(অ্যাপ-ওয়াইড কাস্টমাইজেশনের জন্য) বা domain-config
(প্রতি-ডোমেন কাস্টমাইজেশনের জন্য) ব্যবহার করে আপনার অ্যাপের সংযোগগুলি কাস্টমাইজ করতে পারেন।
একটি কাস্টম CA কনফিগার করুন
আপনি এমন একটি হোস্টের সাথে সংযোগ করতে চাইতে পারেন যা একটি স্ব-স্বাক্ষরিত SSL শংসাপত্র ব্যবহার করে বা এমন একটি হোস্টের সাথে যার SSL শংসাপত্র একটি অ-পাবলিক CA দ্বারা জারি করা হয় যা আপনি বিশ্বাস করেন, যেমন আপনার কোম্পানির অভ্যন্তরীণ CA৷ নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ একটি কাস্টম CA-এর জন্য কীভাবে আপনার অ্যাপ কনফিগার করবেন তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/my_ca
তে PEM বা DER ফর্ম্যাটে স্ব-স্বাক্ষরিত বা অ-সর্বজনীন CA শংসাপত্র যোগ করুন।
বিশ্বস্ত CA-এর সেট সীমিত করুন
আপনি যদি না চান যে আপনার অ্যাপ সিস্টেমের দ্বারা বিশ্বস্ত সমস্ত CA-কে বিশ্বাস করুক, আপনি পরিবর্তে বিশ্বাস করার জন্য CA-এর একটি কম সেট নির্দিষ্ট করতে পারেন। এটি অন্য যেকোন CA দ্বারা জারি করা প্রতারণামূলক শংসাপত্র থেকে অ্যাপটিকে রক্ষা করে৷
বিশ্বস্ত CA-এর সেট সীমিত করার কনফিগারেশন একটি নির্দিষ্ট ডোমেনের জন্য একটি কাস্টম CA-কে বিশ্বাস করার অনুরূপ, রিসোর্সে একাধিক CA প্রদান করা ছাড়া। নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ আপনার অ্যাপের বিশ্বস্ত CA-এর সেটকে কীভাবে সীমাবদ্ধ করতে হয় তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">secure.example.com</domain> <domain includeSubdomains="true">cdn.example.com</domain> <trust-anchors> <certificates src="@raw/trusted_roots"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/trusted_roots
এ PEM বা DER ফর্ম্যাটে বিশ্বস্ত CA যোগ করুন। মনে রাখবেন যে আপনি যদি PEM ফর্ম্যাট ব্যবহার করেন তবে ফাইলটিতে শুধুমাত্র PEM ডেটা থাকতে হবে এবং কোনও অতিরিক্ত পাঠ্য থাকবে না। আপনি একটির পরিবর্তে একাধিক <certificates>
উপাদান প্রদান করতে পারেন।
অতিরিক্ত CA-কে বিশ্বাস করুন
আপনি আপনার অ্যাপটিকে অতিরিক্ত CA-কে বিশ্বাস করতে চাইতে পারেন যেগুলি সিস্টেমের দ্বারা বিশ্বাসযোগ্য নয়, যেমন যদি সিস্টেমটি এখনও CA অন্তর্ভুক্ত না করে বা CA Android সিস্টেমে অন্তর্ভুক্তির প্রয়োজনীয়তাগুলি পূরণ করে না৷ আপনি নিম্নলিখিত উদ্ধৃতির মতো কোড ব্যবহার করে res/xml/network_security_config.xml
এ কনফিগারেশনের জন্য একাধিক শংসাপত্র উত্স নির্দিষ্ট করতে পারেন।
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="@raw/extracas"/> <certificates src="system"/> </trust-anchors> </base-config> </network-security-config>
ডিবাগিংয়ের জন্য CA কনফিগার করুন
HTTPS-এর মাধ্যমে সংযোগকারী একটি অ্যাপ ডিবাগ করার সময়, আপনি একটি স্থানীয় ডেভেলপমেন্ট সার্ভারের সাথে সংযোগ করতে চাইতে পারেন যেখানে আপনার উৎপাদন সার্ভারের জন্য SSL শংসাপত্র নেই। আপনার অ্যাপের কোডে কোনো পরিবর্তন না করেই এটিকে সমর্থন করতে, আপনি debug-overrides
ব্যবহার করে শুধুমাত্র ডিবাগ-অনলি CAগুলি নির্দিষ্ট করতে পারেন, যেগুলি শুধুমাত্র তখনই বিশ্বস্ত হয় যখন android:debuggable true
হয়। সাধারণত, IDEs এবং বিল্ড টুলগুলি এই পতাকাটি অ-মুক্তি বিল্ডগুলির জন্য স্বয়ংক্রিয়ভাবে সেট করে।
এটি সাধারণ শর্তসাপেক্ষ কোডের চেয়ে নিরাপদ কারণ নিরাপত্তা সতর্কতা হিসাবে, অ্যাপ স্টোরগুলি ডিবাগযোগ্য হিসাবে চিহ্নিত অ্যাপগুলিকে গ্রহণ করে না৷
নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml
এ ডিবাগ-শুধুমাত্র CAগুলি নির্দিষ্ট করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <debug-overrides> <trust-anchors> <certificates src="@raw/debug_cas"/> </trust-anchors> </debug-overrides> </network-security-config>
শংসাপত্রের স্বচ্ছতা বেছে নিন
দ্রষ্টব্য: শংসাপত্র স্বচ্ছতা সমর্থন শুধুমাত্র Android 16 (API স্তর 36) থেকে উপলব্ধ।
সার্টিফিকেট ট্রান্সপারেন্সি (CT, RFC 6962 ) হল একটি ইন্টারনেট স্ট্যান্ডার্ড যা ডিজিটাল সার্টিফিকেটের নিরাপত্তা বাড়ানোর জন্য ডিজাইন করা হয়েছে। সার্টিফিকেট প্রদানের প্রক্রিয়ায় স্বচ্ছতা এবং জবাবদিহিতা বৃদ্ধি করে, CA-দের সমস্ত জারি করা শংসাপত্র একটি পাবলিক লগে জমা দিতে হবে যা তাদের রেকর্ড করে।
সমস্ত শংসাপত্রের একটি যাচাইযোগ্য রেকর্ড বজায় রাখার মাধ্যমে, CT দূষিত অভিনেতাদের জন্য শংসাপত্র জাল করা বা CA-এর জন্য ভুলভাবে সেগুলি জারি করাকে উল্লেখযোগ্যভাবে কঠিন করে তোলে৷ এটি ব্যবহারকারীদের ম্যান-ইন-দ্য-মিডল আক্রমণ এবং অন্যান্য নিরাপত্তা হুমকি থেকে রক্ষা করতে সহায়তা করে। আরও তথ্যের জন্য, transparency.dev- এর ব্যাখ্যা দেখুন। Android-এ CT সম্মতি সম্পর্কে আরও তথ্যের জন্য, Android এর CT নীতি দেখুন।
ডিফল্টরূপে, শংসাপত্রগুলি CT লগ-এ লগ-ইন করা হোক না কেন তা গ্রহণ করা হয়। আপনার অ্যাপটি শুধুমাত্র একটি CT লগ ইন করা শংসাপত্রের সাথে গন্তব্যের সাথে সংযোগ করছে তা নিশ্চিত করতে, আপনি বিশ্বব্যাপী বা প্রতি-ডোমেনের ভিত্তিতে বৈশিষ্ট্যটিতে অপ্ট ইন করতে পারেন৷
ক্লিয়ারটেক্সট ট্রাফিক অপ্ট আউট করুন
দ্রষ্টব্য: এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার নিচের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়।
আপনি যদি আপনার অ্যাপটি শুধুমাত্র সুরক্ষিত সংযোগ ব্যবহার করে গন্তব্যগুলির সাথে সংযোগ করতে চান, তাহলে আপনি সেই গন্তব্যগুলিতে সমর্থনকারী ক্লিয়ারটেক্সট (HTTPS এর পরিবর্তে এনক্রিপ্ট করা HTTP প্রোটোকল ব্যবহার করে) অপ্ট আউট করতে পারেন৷ এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উত্স দ্বারা প্রদত্ত URL গুলির পরিবর্তনের কারণে অ্যাপগুলিতে দুর্ঘটনাজনিত রিগ্রেশন প্রতিরোধ করতে সহায়তা করে৷ আরও বিস্তারিত জানার জন্য NetworkSecurityPolicy.isCleartextTrafficPermitted()
দেখুন।
উদাহরণ স্বরূপ, আপনি আপনার অ্যাপটি নিশ্চিত করতে চাইতে পারেন যে secure.example.com
এর সাথে সংযোগগুলি সর্বদা HTTPS-এর মাধ্যমে প্রতিকূল নেটওয়ার্কগুলি থেকে সংবেদনশীল ট্র্যাফিককে সুরক্ষিত করতে হবে৷
নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml
এ ক্লিয়ারটেক্সট থেকে অপ্ট আউট করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </network-security-config>
সার্টিফিকেট পিন করুন
সাধারণত, একটি অ্যাপ সমস্ত প্রাক-ইনস্টল করা CAগুলিকে বিশ্বাস করে৷ যদি এই CA-এর মধ্যে কেউ একটি জালিয়াতি শংসাপত্র জারি করে, তাহলে অ্যাপটি অন-পাথ আক্রমণকারীর থেকে ঝুঁকিতে থাকবে। কিছু অ্যাপ্লিকেশান তাদের বিশ্বাসযোগ্য CA-এর সেট সীমিত করে বা শংসাপত্র পিনিংয়ের মাধ্যমে তাদের গ্রহণযোগ্য শংসাপত্রের সেট সীমিত করতে বেছে নেয়।
সার্টিফিকেট পিনিং পাবলিক কী (X.509 সার্টিফিকেটের SubjectPublicKeyInfo
) হ্যাশের মাধ্যমে সার্টিফিকেটের একটি সেট প্রদান করে করা হয়। একটি শংসাপত্র চেইন তখনই বৈধ হয় যদি শংসাপত্রের চেইনে কমপক্ষে একটি পিন করা পাবলিক কী থাকে৷
মনে রাখবেন, শংসাপত্র পিনিং ব্যবহার করার সময়, আপনার সর্বদা একটি ব্যাকআপ কী অন্তর্ভুক্ত করা উচিত যাতে আপনি যদি নতুন কীগুলিতে স্যুইচ করতে বা CA পরিবর্তন করতে বাধ্য হন (যখন একটি CA শংসাপত্র বা সেই CA-এর মধ্যবর্তীতে পিন করা হয়), আপনার অ্যাপের সংযোগ প্রভাবিত না হয়৷ অন্যথায়, সংযোগ পুনরুদ্ধার করতে আপনাকে অবশ্যই অ্যাপে একটি আপডেট করতে হবে।
অতিরিক্তভাবে, পিনের জন্য মেয়াদ শেষ হওয়ার সময় সেট করা সম্ভব যার পরে পিন করা হয় না। এটি আপডেট করা হয়নি এমন অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে৷ যাইহোক, পিনগুলিতে একটি মেয়াদ শেষ হওয়ার সময় সেট করা আক্রমণকারীদের আপনার পিন করা শংসাপত্রগুলিকে বাইপাস করতে সক্ষম করতে পারে৷
নীচের অংশটি res/xml/network_security_config.xml
এ শংসাপত্রগুলিকে কীভাবে পিন করতে হয় তা দেখায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin> <!-- backup pin --> <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config>
কনফিগারেশন উত্তরাধিকার আচরণ
একটি নির্দিষ্ট কনফিগারেশনে সেট না করা মানগুলি উত্তরাধিকারসূত্রে প্রাপ্ত। কনফিগারেশন ফাইলটি পাঠযোগ্য রাখার সময় এই আচরণটি আরও জটিল কনফিগারেশনের অনুমতি দেয়।
উদাহরণ স্বরূপ, domain-config
এ সেট না করা মানগুলি প্যারেন্ট domain-config
থেকে নেওয়া হয়, যদি নেস্টেড থাকে, অথবা যদি না হয় তাহলে base-config
থেকে নেওয়া হয়। base-config
সেট না করা মানগুলি প্ল্যাটফর্মের ডিফল্ট মান ব্যবহার করে।
উদাহরণ স্বরূপ, একটি কেস বিবেচনা করুন যেখানে example.com
এর সাবডোমেনের সমস্ত সংযোগ অবশ্যই CA-এর একটি কাস্টম সেট ব্যবহার করবে৷ অতিরিক্তভাবে, secure.example.com
এর সাথে সংযোগ করার সময় ছাড়া এই ডোমেনে ক্লিয়ারটেক্সট ট্র্যাফিক অনুমোদিত। example.com
এর কনফিগারেশনের ভিতরে secure.example.com
এর জন্য কনফিগারেশন নেস্ট করার মাধ্যমে, trust-anchors
নকল করার প্রয়োজন নেই।
নীচের অংশটি দেখায় যে এই নেস্টিংটি res/xml/network_security_config.xml
এ কেমন দেখাবে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </domain-config> </network-security-config>
কনফিগারেশন ফাইল ফরম্যাট
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য একটি XML ফাইল বিন্যাস ব্যবহার করে। ফাইলের সামগ্রিক গঠন নিম্নলিখিত কোড নমুনায় দেখানো হয়েছে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </base-config> <domain-config> <domain>android.com</domain> ... <trust-anchors> <certificates src="..."/> ... </trust-anchors> <pin-set> <pin digest="...">...</pin> ... </pin-set> </domain-config> ... <debug-overrides> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </debug-overrides> </network-security-config>
নিম্নলিখিত বিভাগগুলি ফাইল বিন্যাসের সিনট্যাক্স এবং অন্যান্য বিবরণ বর্ণনা করে।
<network-security-config>
- থাকতে পারে:
-
<base-config>
এর 0 বা 1
<domain-config>
এর যেকোনো সংখ্যা
<debug-overrides>
এর 0 বা 1
<base-config>
- সিনট্যাক্স:
<base-config cleartextTrafficPermitted=["true" | "false"]> ... </base-config>
- থাকতে পারে:
-
<trust-anchors>
অ্যাঙ্কর><certificateTransparency>
- বর্ণনা:
- সমস্ত সংযোগ দ্বারা ব্যবহৃত ডিফল্ট কনফিগারেশন যার গন্তব্য একটি
domain-config
দ্বারা আচ্ছাদিত নয়।যে কোনো মান সেট করা নেই প্ল্যাটফর্ম ডিফল্ট মান ব্যবহার করে।
অ্যান্ড্রয়েড 9 (এপিআই স্তর 28) এবং উচ্চতরকে লক্ষ্য করা অ্যাপগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
Android 7.0 (API লেভেল 24) থেকে Android 8.1 (API লেভেল 27) লক্ষ্য করা অ্যাপগুলির ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) এবং তার নিচের অ্যাপ্লিকেশানগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config>
<domain-config>
- সিনট্যাক্স:
<domain-config cleartextTrafficPermitted=["true" | "false"]> ... </domain-config>
- থাকতে পারে:
- 1 বা তার বেশি
<domain>
0 বা 1<certificateTransparency>
>
0 বা 1<trust-anchors>
0 বা 1<pin-set>
সেট>
নেস্টেড<domain-config>
এর যেকোনো সংখ্যা - বর্ণনা:
-
domain
উপাদান দ্বারা সংজ্ঞায়িত নির্দিষ্ট গন্তব্যের সাথে সংযোগের জন্য ব্যবহৃত কনফিগারেশন।মনে রাখবেন যে যদি একাধিক
domain-config
উপাদান একটি গন্তব্যকে কভার করে, তবে সবচেয়ে নির্দিষ্ট (দীর্ঘতম) মিলিত ডোমেন নিয়মের সাথে কনফিগারেশন ব্যবহার করা হয়।
<ডোমেইন>
- সিনট্যাক্স:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
- গুণাবলী:
-
includeSubdomains
- যদি
"true"
, তাহলে এই ডোমেন নিয়মটি ডোমেন এবং সাবডোমেনের সাবডোমেন সহ সমস্ত সাবডোমেনের সাথে মেলে। অন্যথায়, নিয়ম শুধুমাত্র সঠিক মিলের ক্ষেত্রে প্রযোজ্য।
-
<সার্টিফিকেট স্বচ্ছতা>
- সিনট্যাক্স:
<certificateTransparency enabled=["true" | "false"]/>
- বর্ণনা:
- যদি
true
, তাহলে অ্যাপটি শংসাপত্রগুলি যাচাই করতে শংসাপত্রের স্বচ্ছতা লগগুলি ব্যবহার করবে৷ যখন একটি অ্যাপ তার নিজস্ব শংসাপত্র (বা ব্যবহারকারীর দোকান) ব্যবহার করে, তখন সম্ভবত শংসাপত্রটি সর্বজনীন নয় এবং তাই শংসাপত্রের স্বচ্ছতা ব্যবহার করে যাচাইযোগ্য নয়৷ ডিফল্টরূপে, এই ক্ষেত্রে যাচাইকরণ নিষ্ক্রিয় করা হয়। এখনও ডোমেন কনফিগারেশনে<certificateTransparency enabled="true"/>
ব্যবহার করে যাচাইকরণ জোর করা সম্ভব। প্রতিটি<domain-config>
এর জন্য, মূল্যায়ন এই ক্রম অনুসরণ করে:-
certificateTransparency
সক্ষম হলে, যাচাইকরণ সক্ষম করুন৷ - যদি কোনো
<trust-anchors>
হয়"user"
বা ইনলাইন (যেমন,"@raw/cert.pem"
), যাচাইকরণ অক্ষম করুন। - অন্যথায়, উত্তরাধিকারসূত্রে প্রাপ্ত কনফিগারেশনের উপর নির্ভর করুন।
-
<debug-overrides>
- সিনট্যাক্স:
<debug-overrides> ... </debug-overrides>
- থাকতে পারে:
- 0 বা 1
<trust-anchors>
- বর্ণনা:
- android:debuggable যখন
"true"
হয় তখন ওভাররাইড প্রয়োগ করা হয়, যা সাধারণত IDEs এবং বিল্ড টুলস দ্বারা উত্পন্ন নন-রিলিজ বিল্ডগুলির ক্ষেত্রে হয়৷debug-overrides
নির্দিষ্ট করা ট্রাস্ট অ্যাঙ্করগুলি অন্যান্য সমস্ত কনফিগারেশনে যোগ করা হয় এবং সার্ভারের শংসাপত্র চেইন যখন এই ডিবাগ-অনলি ট্রাস্ট অ্যাঙ্করগুলির মধ্যে একটি ব্যবহার করে তখন শংসাপত্র পিন করা হয় না। যদি android:debuggable হয়"false"
, তাহলে এই বিভাগটিকে সম্পূর্ণরূপে উপেক্ষা করা হয়৷
<ট্রাস্ট-অ্যাঙ্করস>
- সিনট্যাক্স:
<trust-anchors> ... </trust-anchors>
- থাকতে পারে:
- যে কোন সংখ্যা
<certificates>
সার্টিফিকেট> - বর্ণনা:
- নিরাপদ সংযোগের জন্য বিশ্বস্ত অ্যাঙ্করগুলির সেট৷
<সার্টিফিকেট>
- সিনট্যাক্স:
<certificates src=["system" | "user" | "raw resource"] overridePins=["true" | "false"] />
- বর্ণনা:
-
trust-anchors
উপাদানগুলির জন্য X.509 শংসাপত্রের সেট। - গুণাবলী:
-
src
- CA সার্টিফিকেটের উৎস। প্রতিটি শংসাপত্র নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
- X.509 সার্টিফিকেট ধারণকারী একটি ফাইলের দিকে নির্দেশ করে একটি কাঁচা সম্পদ আইডি। শংসাপত্রগুলি DER বা PEM ফর্ম্যাটে এনকোড করা আবশ্যক৷ PEM শংসাপত্রের ক্ষেত্রে, ফাইলটিতে মন্তব্যের মতো অতিরিক্ত নন-PEM ডেটা থাকতে হবে না ।
- প্রাক-ইনস্টল করা সিস্টেম CA সার্টিফিকেটের জন্য
"system"
- ব্যবহারকারী-সংযুক্ত CA শংসাপত্রের জন্য
"user"
-
overridePins
যদি এই উৎস থেকে CA বাইপাস শংসাপত্র পিনিং হয় তা নির্দিষ্ট করে৷ যদি
"true"
, তাহলে শংসাপত্রের চেইনে পিনিং করা হয় না যা এই উৎস থেকে CA-এর একজন দ্বারা স্বাক্ষরিত। এটি CA ডিবাগ করার জন্য বা আপনার অ্যাপের নিরাপদ ট্র্যাফিকের ম্যান-ইন-দ্য-মিডল আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।debug-overrides
এলিমেন্টে নির্দিষ্ট করা না থাকলে ডিফল্ট"false"
হয়, যে ক্ষেত্রে ডিফল্টটি"true"
।
-
<পিন-সেট>
- সিনট্যাক্স:
<pin-set expiration="date"> ... </pin-set>
- থাকতে পারে:
-
<pin>
এর যেকোনো সংখ্যা - বর্ণনা:
- পাবলিক কী পিনের একটি সেট। একটি নিরাপদ সংযোগ বিশ্বস্ত হওয়ার জন্য, বিশ্বাসের চেইনের সর্বজনীন কীগুলির মধ্যে একটি পিনের সেটে থাকা আবশ্যক৷ পিনের বিন্যাসের জন্য
<pin>
দেখুন। - গুণাবলী:
-
expiration
- তারিখ,
yyyy-MM-dd
বিন্যাসে, যেটিতে পিনগুলির মেয়াদ শেষ হয়ে যায়, এইভাবে পিন করা অক্ষম করে৷ যদি অ্যাট্রিবিউট সেট করা না থাকে, তাহলে পিনের মেয়াদ শেষ হয় না।মেয়াদ শেষ হওয়া অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে যেগুলি তাদের পিন সেটের আপডেট পায় না, যেমন ব্যবহারকারী যখন অ্যাপ আপডেটগুলি অক্ষম করে।
-
<পিন>
- সিনট্যাক্স:
<pin digest=["SHA-256"]>base64 encoded digest of X.509 SubjectPublicKeyInfo (SPKI)</pin>
- গুণাবলী:
-
digest
- পিন তৈরি করতে ব্যবহৃত ডাইজেস্ট অ্যালগরিদম। বর্তমানে, শুধুমাত্র
"SHA-256"
সমর্থিত।
-
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য আপনাকে অ্যাপ কোড পরিবর্তন না করেই একটি নিরাপদ, ঘোষণামূলক কনফিগারেশন ফাইলে আপনার অ্যাপের নেটওয়ার্ক নিরাপত্তা সেটিংস কাস্টমাইজ করতে দেয়। এই সেটিংস নির্দিষ্ট ডোমেন এবং একটি নির্দিষ্ট অ্যাপের জন্য কনফিগার করা যেতে পারে। এই বৈশিষ্ট্যের মূল ক্ষমতা হল:
- কাস্টম ট্রাস্ট অ্যাঙ্কর: একটি অ্যাপের সুরক্ষিত সংযোগের জন্য কোন সার্টিফিকেট অথরিটি (CA) বিশ্বস্ত তা কাস্টমাইজ করুন। উদাহরণস্বরূপ, নির্দিষ্ট স্ব-স্বাক্ষরিত শংসাপত্রগুলিতে বিশ্বাস করা বা অ্যাপটি বিশ্বাস করে এমন পাবলিক CA-এর সেটকে সীমাবদ্ধ করা৷
- ডিবাগ-অনলি ওভাররাইড: ইনস্টল করা বেসে অতিরিক্ত ঝুঁকি ছাড়াই একটি অ্যাপে নিরাপদে সুরক্ষিত সংযোগ ডিবাগ করুন।
- ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট: ক্লিয়ারটেক্সট (অএনক্রিপ্ট করা) ট্র্যাফিকের দুর্ঘটনাজনিত ব্যবহার থেকে অ্যাপগুলিকে রক্ষা করুন।
- শংসাপত্রের স্বচ্ছতা অপ্ট-ইন: প্রমাণিতভাবে লগ করা শংসাপত্রগুলি ব্যবহার করতে একটি অ্যাপের সুরক্ষিত সংযোগগুলিকে সীমাবদ্ধ করুন৷
- শংসাপত্র পিনিং: নির্দিষ্ট শংসাপত্রের সাথে একটি অ্যাপের সুরক্ষিত সংযোগ সীমাবদ্ধ করুন।
একটি নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল যোগ করুন
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্যটি একটি XML ফাইল ব্যবহার করে যেখানে আপনি আপনার অ্যাপের জন্য সেটিংস নির্দিষ্ট করেন। এই ফাইলটি নির্দেশ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে একটি এন্ট্রি অন্তর্ভুক্ত করতে হবে৷ একটি ম্যানিফেস্ট থেকে নিম্নলিখিত কোড উদ্ধৃতি প্রদর্শন করে কিভাবে এই এন্ট্রি তৈরি করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <manifest ... > <application android:networkSecurityConfig="@xml/network_security_config" ... > ... </application> </manifest>
বিশ্বস্ত CA কাস্টমাইজ করুন
আপনি প্ল্যাটফর্ম ডিফল্টের পরিবর্তে আপনার অ্যাপটি CA-এর একটি কাস্টম সেট বিশ্বাস করতে চাইতে পারেন। এর জন্য সবচেয়ে সাধারণ কারণগুলি হল:
- একটি কাস্টম CA সহ একটি হোস্টের সাথে সংযোগ করা, যেমন একটি CA যা স্ব-স্বাক্ষরিত বা একটি কোম্পানির মধ্যে অভ্যন্তরীণভাবে জারি করা হয়৷
- প্রতিটি প্রি-ইনস্টল করা CA-এর পরিবর্তে শুধুমাত্র আপনার বিশ্বাসযোগ্য CA-এর মধ্যে CA-এর সেট সীমাবদ্ধ করা।
- সিস্টেমে অন্তর্ভুক্ত নয় অতিরিক্ত CA-কে বিশ্বাস করা।
ডিফল্টরূপে, সমস্ত অ্যাপ থেকে সুরক্ষিত সংযোগগুলি (TLS এবং HTTPS-এর মতো প্রোটোকল ব্যবহার করে) আগে থেকে ইনস্টল করা সিস্টেম CA-কে বিশ্বাস করে এবং Android 6.0 (API লেভেল 23) এবং নিম্নতর অ্যাপ্লিকেশানগুলিকে লক্ষ্য করে ডিফল্টভাবে ব্যবহারকারী-যুক্ত CA স্টোরকেও বিশ্বাস করে৷ আপনি base-config
(অ্যাপ-ওয়াইড কাস্টমাইজেশনের জন্য) বা domain-config
(প্রতি-ডোমেন কাস্টমাইজেশনের জন্য) ব্যবহার করে আপনার অ্যাপের সংযোগগুলি কাস্টমাইজ করতে পারেন।
একটি কাস্টম CA কনফিগার করুন
আপনি এমন একটি হোস্টের সাথে সংযোগ করতে চাইতে পারেন যা একটি স্ব-স্বাক্ষরিত SSL শংসাপত্র ব্যবহার করে বা এমন একটি হোস্টের সাথে যার SSL শংসাপত্র একটি অ-পাবলিক CA দ্বারা জারি করা হয় যা আপনি বিশ্বাস করেন, যেমন আপনার কোম্পানির অভ্যন্তরীণ CA৷ নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ একটি কাস্টম CA-এর জন্য কীভাবে আপনার অ্যাপ কনফিগার করবেন তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/my_ca
তে PEM বা DER ফর্ম্যাটে স্ব-স্বাক্ষরিত বা অ-সর্বজনীন CA শংসাপত্র যোগ করুন।
বিশ্বস্ত CA-এর সেট সীমিত করুন
আপনি যদি না চান যে আপনার অ্যাপ সিস্টেমের দ্বারা বিশ্বস্ত সমস্ত CA-কে বিশ্বাস করুক, আপনি পরিবর্তে বিশ্বাস করার জন্য CA-এর একটি কম সেট নির্দিষ্ট করতে পারেন। এটি অন্য যেকোন CA দ্বারা জারি করা প্রতারণামূলক শংসাপত্র থেকে অ্যাপটিকে রক্ষা করে৷
বিশ্বস্ত CA-এর সেট সীমিত করার কনফিগারেশন একটি নির্দিষ্ট ডোমেনের জন্য একটি কাস্টম CA-কে বিশ্বাস করার অনুরূপ, রিসোর্সে একাধিক CA প্রদান করা ছাড়া। নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ আপনার অ্যাপের বিশ্বস্ত CA-এর সেটকে কীভাবে সীমাবদ্ধ করতে হয় তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">secure.example.com</domain> <domain includeSubdomains="true">cdn.example.com</domain> <trust-anchors> <certificates src="@raw/trusted_roots"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/trusted_roots
এ PEM বা DER ফর্ম্যাটে বিশ্বস্ত CA যোগ করুন। মনে রাখবেন যে আপনি যদি PEM ফর্ম্যাট ব্যবহার করেন তবে ফাইলটিতে শুধুমাত্র PEM ডেটা থাকতে হবে এবং কোনও অতিরিক্ত পাঠ্য থাকবে না। আপনি একটির পরিবর্তে একাধিক <certificates>
উপাদান প্রদান করতে পারেন।
অতিরিক্ত CA-কে বিশ্বাস করুন
আপনি আপনার অ্যাপটিকে অতিরিক্ত CA-কে বিশ্বাস করতে চাইতে পারেন যেগুলি সিস্টেমের দ্বারা বিশ্বাসযোগ্য নয়, যেমন যদি সিস্টেমটি এখনও CA অন্তর্ভুক্ত না করে বা CA Android সিস্টেমে অন্তর্ভুক্তির প্রয়োজনীয়তাগুলি পূরণ করে না৷ আপনি নিম্নলিখিত উদ্ধৃতির মতো কোড ব্যবহার করে res/xml/network_security_config.xml
এ কনফিগারেশনের জন্য একাধিক শংসাপত্র উত্স নির্দিষ্ট করতে পারেন।
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="@raw/extracas"/> <certificates src="system"/> </trust-anchors> </base-config> </network-security-config>
ডিবাগিংয়ের জন্য CA কনফিগার করুন
HTTPS-এর মাধ্যমে সংযোগকারী একটি অ্যাপ ডিবাগ করার সময়, আপনি একটি স্থানীয় ডেভেলপমেন্ট সার্ভারের সাথে সংযোগ করতে চাইতে পারেন যেখানে আপনার উৎপাদন সার্ভারের জন্য SSL শংসাপত্র নেই। আপনার অ্যাপের কোডে কোনো পরিবর্তন না করেই এটিকে সমর্থন করতে, আপনি debug-overrides
ব্যবহার করে শুধুমাত্র ডিবাগ-অনলি CAগুলি নির্দিষ্ট করতে পারেন, যেগুলি শুধুমাত্র তখনই বিশ্বস্ত হয় যখন android:debuggable true
হয়। সাধারণত, IDEs এবং বিল্ড টুলগুলি এই পতাকাটি অ-মুক্তি বিল্ডগুলির জন্য স্বয়ংক্রিয়ভাবে সেট করে।
এটি সাধারণ শর্তসাপেক্ষ কোডের চেয়ে নিরাপদ কারণ নিরাপত্তা সতর্কতা হিসাবে, অ্যাপ স্টোরগুলি ডিবাগযোগ্য হিসাবে চিহ্নিত অ্যাপগুলিকে গ্রহণ করে না৷
নীচের উদ্ধৃতিটি res/xml/network_security_config.xml
এ ডিবাগ-অনলি CAগুলি কীভাবে নির্দিষ্ট করতে হয় তা দেখায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <debug-overrides> <trust-anchors> <certificates src="@raw/debug_cas"/> </trust-anchors> </debug-overrides> </network-security-config>
শংসাপত্রের স্বচ্ছতা বেছে নিন
দ্রষ্টব্য: শংসাপত্র স্বচ্ছতা সমর্থন শুধুমাত্র Android 16 (API স্তর 36) থেকে উপলব্ধ।
সার্টিফিকেট ট্রান্সপারেন্সি (CT, RFC 6962 ) হল একটি ইন্টারনেট স্ট্যান্ডার্ড যা ডিজিটাল সার্টিফিকেটের নিরাপত্তা বাড়ানোর জন্য ডিজাইন করা হয়েছে। সার্টিফিকেট প্রদানের প্রক্রিয়ায় স্বচ্ছতা এবং জবাবদিহিতা বৃদ্ধি করে, CA-দের সমস্ত জারি করা শংসাপত্র একটি পাবলিক লগে জমা দিতে হবে যা তাদের রেকর্ড করে।
সমস্ত শংসাপত্রের একটি যাচাইযোগ্য রেকর্ড বজায় রাখার মাধ্যমে, CT দূষিত অভিনেতাদের জন্য শংসাপত্র জাল করা বা CA-এর জন্য ভুলভাবে সেগুলি জারি করাকে উল্লেখযোগ্যভাবে কঠিন করে তোলে৷ এটি ব্যবহারকারীদের ম্যান-ইন-দ্য-মিডল আক্রমণ এবং অন্যান্য নিরাপত্তা হুমকি থেকে রক্ষা করতে সহায়তা করে। আরও তথ্যের জন্য, transparency.dev- এর ব্যাখ্যা দেখুন। Android-এ CT সম্মতি সম্পর্কে আরও তথ্যের জন্য, Android এর CT নীতি দেখুন।
ডিফল্টরূপে, শংসাপত্রগুলি CT লগ-এ লগ-ইন করা হোক না কেন তা গ্রহণ করা হয়। আপনার অ্যাপটি শুধুমাত্র একটি CT লগ ইন করা শংসাপত্রের সাথে গন্তব্যের সাথে সংযোগ করছে তা নিশ্চিত করতে, আপনি বিশ্বব্যাপী বা প্রতি-ডোমেনের ভিত্তিতে বৈশিষ্ট্যটিতে অপ্ট ইন করতে পারেন৷
ক্লিয়ারটেক্সট ট্রাফিক অপ্ট আউট করুন
দ্রষ্টব্য: এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার নিচের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়।
আপনি যদি আপনার অ্যাপটি শুধুমাত্র সুরক্ষিত সংযোগ ব্যবহার করে গন্তব্যগুলির সাথে সংযোগ করতে চান, তাহলে আপনি সেই গন্তব্যগুলিতে সমর্থনকারী ক্লিয়ারটেক্সট (HTTPS এর পরিবর্তে এনক্রিপ্ট করা HTTP প্রোটোকল ব্যবহার করে) অপ্ট আউট করতে পারেন৷ এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উত্স দ্বারা প্রদত্ত URL গুলির পরিবর্তনের কারণে অ্যাপগুলিতে দুর্ঘটনাজনিত রিগ্রেশন প্রতিরোধ করতে সহায়তা করে৷ আরও বিস্তারিত জানার জন্য NetworkSecurityPolicy.isCleartextTrafficPermitted()
দেখুন।
উদাহরণ স্বরূপ, আপনি আপনার অ্যাপটি নিশ্চিত করতে চাইতে পারেন যে secure.example.com
এর সাথে সংযোগগুলি সর্বদা HTTPS-এর মাধ্যমে প্রতিকূল নেটওয়ার্কগুলি থেকে সংবেদনশীল ট্র্যাফিককে সুরক্ষিত করতে হবে৷
নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml
এ ক্লিয়ারটেক্সট থেকে অপ্ট আউট করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </network-security-config>
সার্টিফিকেট পিন করুন
সাধারণত, একটি অ্যাপ সমস্ত প্রাক-ইনস্টল করা CAগুলিকে বিশ্বাস করে৷ যদি এই CA-এর মধ্যে কেউ একটি জালিয়াতি শংসাপত্র জারি করে, তাহলে অ্যাপটি অন-পাথ আক্রমণকারীর থেকে ঝুঁকিতে থাকবে। কিছু অ্যাপ্লিকেশান তাদের বিশ্বাসযোগ্য CA-এর সেট সীমিত করে বা শংসাপত্র পিনিংয়ের মাধ্যমে তাদের গ্রহণযোগ্য শংসাপত্রের সেট সীমিত করতে বেছে নেয়।
সার্টিফিকেট পিনিং পাবলিক কী (X.509 সার্টিফিকেটের SubjectPublicKeyInfo
) হ্যাশের মাধ্যমে সার্টিফিকেটের একটি সেট প্রদান করে করা হয়। একটি শংসাপত্র চেইন তখনই বৈধ হয় যদি শংসাপত্রের চেইনে কমপক্ষে একটি পিন করা পাবলিক কী থাকে৷
মনে রাখবেন, শংসাপত্র পিনিং ব্যবহার করার সময়, আপনার সর্বদা একটি ব্যাকআপ কী অন্তর্ভুক্ত করা উচিত যাতে আপনি যদি নতুন কীগুলিতে স্যুইচ করতে বা CA পরিবর্তন করতে বাধ্য হন (যখন একটি CA শংসাপত্র বা সেই CA-এর মধ্যবর্তীতে পিন করা হয়), আপনার অ্যাপের সংযোগ প্রভাবিত না হয়৷ অন্যথায়, সংযোগ পুনরুদ্ধার করতে আপনাকে অবশ্যই অ্যাপে একটি আপডেট করতে হবে।
অতিরিক্তভাবে, পিনের জন্য মেয়াদ শেষ হওয়ার সময় সেট করা সম্ভব যার পরে পিন করা হয় না। এটি আপডেট করা হয়নি এমন অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে৷ যাইহোক, পিনগুলিতে একটি মেয়াদ শেষ হওয়ার সময় সেট করা আক্রমণকারীদের আপনার পিন করা শংসাপত্রগুলিকে বাইপাস করতে সক্ষম করতে পারে৷
নীচের অংশটি res/xml/network_security_config.xml
এ শংসাপত্রগুলিকে কীভাবে পিন করতে হয় তা দেখায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin> <!-- backup pin --> <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config>
কনফিগারেশন উত্তরাধিকার আচরণ
একটি নির্দিষ্ট কনফিগারেশনে সেট না করা মানগুলি উত্তরাধিকারসূত্রে প্রাপ্ত। কনফিগারেশন ফাইলটি পাঠযোগ্য রাখার সময় এই আচরণটি আরও জটিল কনফিগারেশনের অনুমতি দেয়।
উদাহরণ স্বরূপ, domain-config
এ সেট না করা মানগুলি প্যারেন্ট domain-config
থেকে নেওয়া হয়, যদি নেস্টেড থাকে, অথবা যদি না হয় তাহলে base-config
থেকে নেওয়া হয়। base-config
সেট না করা মানগুলি প্ল্যাটফর্মের ডিফল্ট মান ব্যবহার করে।
উদাহরণ স্বরূপ, একটি কেস বিবেচনা করুন যেখানে example.com
এর সাবডোমেনের সমস্ত সংযোগ অবশ্যই CA-এর একটি কাস্টম সেট ব্যবহার করবে৷ অতিরিক্তভাবে, secure.example.com
এর সাথে সংযোগ করার সময় ছাড়া এই ডোমেনে ক্লিয়ারটেক্সট ট্র্যাফিক অনুমোদিত। example.com
এর কনফিগারেশনের ভিতরে secure.example.com
এর জন্য কনফিগারেশন নেস্ট করার মাধ্যমে, trust-anchors
নকল করার প্রয়োজন নেই।
নীচের অংশটি দেখায় যে এই নেস্টিংটি res/xml/network_security_config.xml
এ কেমন দেখাবে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </domain-config> </network-security-config>
কনফিগারেশন ফাইল ফরম্যাট
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য একটি XML ফাইল বিন্যাস ব্যবহার করে। ফাইলের সামগ্রিক গঠন নিম্নলিখিত কোড নমুনায় দেখানো হয়েছে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </base-config> <domain-config> <domain>android.com</domain> ... <trust-anchors> <certificates src="..."/> ... </trust-anchors> <pin-set> <pin digest="...">...</pin> ... </pin-set> </domain-config> ... <debug-overrides> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </debug-overrides> </network-security-config>
নিম্নলিখিত বিভাগগুলি ফাইল বিন্যাসের সিনট্যাক্স এবং অন্যান্য বিবরণ বর্ণনা করে।
<network-security-config>
- থাকতে পারে:
-
<base-config>
এর 0 বা 1
<domain-config>
এর যেকোনো সংখ্যা
<debug-overrides>
এর 0 বা 1
<base-config>
- সিনট্যাক্স:
<base-config cleartextTrafficPermitted=["true" | "false"]> ... </base-config>
- থাকতে পারে:
-
<trust-anchors>
<certificateTransparency>
- বর্ণনা:
- সমস্ত সংযোগ দ্বারা ব্যবহৃত ডিফল্ট কনফিগারেশন যার গন্তব্য একটি
domain-config
দ্বারা আচ্ছাদিত নয়।যে কোনো মান সেট করা নেই প্ল্যাটফর্ম ডিফল্ট মান ব্যবহার করে।
অ্যান্ড্রয়েড 9 (এপিআই স্তর 28) এবং উচ্চতরকে লক্ষ্য করা অ্যাপগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
Android 7.0 (API লেভেল 24) থেকে Android 8.1 (API লেভেল 27) লক্ষ্য করা অ্যাপগুলির ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) এবং তার নিচের অ্যাপ্লিকেশানগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config>
<domain-config>
- সিনট্যাক্স:
<domain-config cleartextTrafficPermitted=["true" | "false"]> ... </domain-config>
- থাকতে পারে:
- 1 বা তার বেশি
<domain>
0 বা 1<certificateTransparency>
>
0 বা 1<trust-anchors>
0 বা 1<pin-set>
সেট>
নেস্টেড<domain-config>
এর যেকোনো সংখ্যা - বর্ণনা:
-
domain
উপাদান দ্বারা সংজ্ঞায়িত নির্দিষ্ট গন্তব্যের সাথে সংযোগের জন্য ব্যবহৃত কনফিগারেশন।মনে রাখবেন যে যদি একাধিক
domain-config
উপাদান একটি গন্তব্যকে কভার করে, তবে সবচেয়ে নির্দিষ্ট (দীর্ঘতম) মিলিত ডোমেন নিয়মের সাথে কনফিগারেশন ব্যবহার করা হয়।
<ডোমেইন>
- সিনট্যাক্স:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
- গুণাবলী:
-
includeSubdomains
- যদি
"true"
, তাহলে এই ডোমেন নিয়মটি ডোমেন এবং সাবডোমেনের সাবডোমেন সহ সমস্ত সাবডোমেনের সাথে মেলে। অন্যথায়, নিয়ম শুধুমাত্র সঠিক মিলের ক্ষেত্রে প্রযোজ্য।
-
<সার্টিফিকেট স্বচ্ছতা>
- সিনট্যাক্স:
<certificateTransparency enabled=["true" | "false"]/>
- বর্ণনা:
- যদি
true
, তাহলে অ্যাপটি শংসাপত্রগুলি যাচাই করতে শংসাপত্রের স্বচ্ছতা লগগুলি ব্যবহার করবে৷ যখন একটি অ্যাপ তার নিজস্ব শংসাপত্র (বা ব্যবহারকারীর দোকান) ব্যবহার করে, তখন সম্ভবত শংসাপত্রটি সর্বজনীন নয় এবং তাই শংসাপত্রের স্বচ্ছতা ব্যবহার করে যাচাইযোগ্য নয়৷ ডিফল্টরূপে, এই ক্ষেত্রে যাচাইকরণ নিষ্ক্রিয় করা হয়। এখনও ডোমেন কনফিগারেশনে<certificateTransparency enabled="true"/>
ব্যবহার করে যাচাইকরণ জোর করা সম্ভব। প্রতিটি<domain-config>
এর জন্য, মূল্যায়ন এই ক্রম অনুসরণ করে:-
certificateTransparency
সক্ষম হলে, যাচাইকরণ সক্ষম করুন৷ - যদি কোনো
<trust-anchors>
হয়"user"
বা ইনলাইন (যেমন,"@raw/cert.pem"
), যাচাইকরণ অক্ষম করুন। - অন্যথায়, উত্তরাধিকারসূত্রে প্রাপ্ত কনফিগারেশনের উপর নির্ভর করুন।
-
<debug-overrides>
- সিনট্যাক্স:
<debug-overrides> ... </debug-overrides>
- থাকতে পারে:
- 0 বা 1
<trust-anchors>
- বর্ণনা:
- android:debuggable যখন
"true"
হয় তখন ওভাররাইড প্রয়োগ করা হয়, যা সাধারণত IDEs এবং বিল্ড টুলস দ্বারা উত্পন্ন নন-রিলিজ বিল্ডগুলির ক্ষেত্রে হয়৷debug-overrides
নির্দিষ্ট করা ট্রাস্ট অ্যাঙ্করগুলি অন্যান্য সমস্ত কনফিগারেশনে যোগ করা হয় এবং সার্ভারের শংসাপত্র চেইন যখন এই ডিবাগ-অনলি ট্রাস্ট অ্যাঙ্করগুলির মধ্যে একটি ব্যবহার করে তখন শংসাপত্র পিন করা হয় না। যদি android:debuggable হয়"false"
, তাহলে এই বিভাগটিকে সম্পূর্ণরূপে উপেক্ষা করা হয়৷
<ট্রাস্ট-অ্যাঙ্করস>
- সিনট্যাক্স:
<trust-anchors> ... </trust-anchors>
- থাকতে পারে:
- যে কোন সংখ্যা
<certificates>
সার্টিফিকেট> - বর্ণনা:
- নিরাপদ সংযোগের জন্য বিশ্বস্ত অ্যাঙ্করগুলির সেট৷
<সার্টিফিকেট>
- সিনট্যাক্স:
<certificates src=["system" | "user" | "raw resource"] overridePins=["true" | "false"] />
- বর্ণনা:
-
trust-anchors
উপাদানগুলির জন্য X.509 শংসাপত্রের সেট। - গুণাবলী:
-
src
- CA সার্টিফিকেটের উৎস। প্রতিটি শংসাপত্র নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
- X.509 সার্টিফিকেট ধারণকারী একটি ফাইলের দিকে নির্দেশ করে একটি কাঁচা সম্পদ আইডি। শংসাপত্রগুলি DER বা PEM ফর্ম্যাটে এনকোড করা আবশ্যক৷ PEM শংসাপত্রের ক্ষেত্রে, ফাইলটিতে মন্তব্যের মতো অতিরিক্ত নন-PEM ডেটা থাকতে হবে না ।
- প্রাক-ইনস্টল করা সিস্টেম CA সার্টিফিকেটের জন্য
"system"
- ব্যবহারকারী-সংযুক্ত CA শংসাপত্রের জন্য
"user"
-
overridePins
যদি এই উৎস থেকে CA বাইপাস শংসাপত্র পিনিং হয় তা নির্দিষ্ট করে৷ যদি
"true"
, তাহলে শংসাপত্রের চেইনে পিনিং করা হয় না যা এই উৎস থেকে CA-এর একজন দ্বারা স্বাক্ষরিত। এটি CA ডিবাগ করার জন্য বা আপনার অ্যাপের নিরাপদ ট্র্যাফিকের ম্যান-ইন-দ্য-মিডল আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।debug-overrides
এলিমেন্টে নির্দিষ্ট করা না থাকলে ডিফল্ট"false"
হয়, যে ক্ষেত্রে ডিফল্টটি"true"
।
-
<পিন-সেট>
- সিনট্যাক্স:
<pin-set expiration="date"> ... </pin-set>
- থাকতে পারে:
-
<pin>
এর যেকোনো সংখ্যা - বর্ণনা:
- পাবলিক কী পিনের একটি সেট। একটি নিরাপদ সংযোগ বিশ্বস্ত হওয়ার জন্য, বিশ্বাসের চেইনের সর্বজনীন কীগুলির মধ্যে একটি পিনের সেটে থাকা আবশ্যক৷ পিনের বিন্যাসের জন্য
<pin>
দেখুন। - গুণাবলী:
-
expiration
- তারিখ,
yyyy-MM-dd
বিন্যাসে, যেটিতে পিনগুলির মেয়াদ শেষ হয়ে যায়, এইভাবে পিন করা অক্ষম করে৷ যদি অ্যাট্রিবিউট সেট করা না থাকে, তাহলে পিনের মেয়াদ শেষ হয় না।মেয়াদ শেষ হওয়া অ্যাপগুলিতে সংযোগ সমস্যা প্রতিরোধ করতে সাহায্য করে যেগুলি তাদের পিন সেটের আপডেট পায় না, যেমন ব্যবহারকারী যখন অ্যাপ আপডেটগুলি অক্ষম করে।
-
<পিন>
- সিনট্যাক্স:
<pin digest=["SHA-256"]>base64 encoded digest of X.509 SubjectPublicKeyInfo (SPKI)</pin>
- গুণাবলী:
-
digest
- পিন তৈরি করতে ব্যবহৃত ডাইজেস্ট অ্যালগরিদম। বর্তমানে, শুধুমাত্র
"SHA-256"
সমর্থিত।
-
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্য আপনাকে অ্যাপ কোড পরিবর্তন না করেই একটি নিরাপদ, ঘোষণামূলক কনফিগারেশন ফাইলে আপনার অ্যাপের নেটওয়ার্ক নিরাপত্তা সেটিংস কাস্টমাইজ করতে দেয়। এই সেটিংস নির্দিষ্ট ডোমেন এবং একটি নির্দিষ্ট অ্যাপের জন্য কনফিগার করা যেতে পারে। এই বৈশিষ্ট্যের মূল ক্ষমতা হল:
- কাস্টম ট্রাস্ট অ্যাঙ্কর: একটি অ্যাপের সুরক্ষিত সংযোগের জন্য কোন সার্টিফিকেট অথরিটি (CA) বিশ্বস্ত তা কাস্টমাইজ করুন। উদাহরণস্বরূপ, নির্দিষ্ট স্ব-স্বাক্ষরিত শংসাপত্রগুলিতে বিশ্বাস করা বা অ্যাপটি বিশ্বাস করে এমন পাবলিক CA-এর সেটকে সীমাবদ্ধ করা৷
- ডিবাগ-অনলি ওভাররাইড: ইনস্টল করা বেসে অতিরিক্ত ঝুঁকি ছাড়াই একটি অ্যাপে নিরাপদে সুরক্ষিত সংযোগ ডিবাগ করুন।
- ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট: ক্লিয়ারটেক্সট (অএনক্রিপ্ট করা) ট্র্যাফিকের দুর্ঘটনাজনিত ব্যবহার থেকে অ্যাপগুলিকে রক্ষা করুন।
- শংসাপত্রের স্বচ্ছতা অপ্ট-ইন: প্রমাণিতভাবে লগ করা শংসাপত্রগুলি ব্যবহার করতে একটি অ্যাপের সুরক্ষিত সংযোগগুলিকে সীমাবদ্ধ করুন৷
- শংসাপত্র পিনিং: নির্দিষ্ট শংসাপত্রের সাথে একটি অ্যাপের সুরক্ষিত সংযোগ সীমাবদ্ধ করুন।
একটি নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল যোগ করুন
নেটওয়ার্ক নিরাপত্তা কনফিগারেশন বৈশিষ্ট্যটি একটি XML ফাইল ব্যবহার করে যেখানে আপনি আপনার অ্যাপের জন্য সেটিংস নির্দিষ্ট করেন। এই ফাইলটি নির্দেশ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে একটি এন্ট্রি অন্তর্ভুক্ত করতে হবে৷ একটি ম্যানিফেস্ট থেকে নিম্নলিখিত কোড উদ্ধৃতি প্রদর্শন করে কিভাবে এই এন্ট্রি তৈরি করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <manifest ... > <application android:networkSecurityConfig="@xml/network_security_config" ... > ... </application> </manifest>
বিশ্বস্ত CA কাস্টমাইজ করুন
আপনি প্ল্যাটফর্ম ডিফল্টের পরিবর্তে আপনার অ্যাপটি CA-এর একটি কাস্টম সেট বিশ্বাস করতে চাইতে পারেন। এর জন্য সবচেয়ে সাধারণ কারণগুলি হল:
- একটি কাস্টম CA সহ একটি হোস্টের সাথে সংযোগ করা, যেমন একটি CA যা স্ব-স্বাক্ষরিত বা একটি কোম্পানির মধ্যে অভ্যন্তরীণভাবে জারি করা হয়৷
- প্রতিটি প্রি-ইনস্টল করা CA-এর পরিবর্তে শুধুমাত্র আপনার বিশ্বাসযোগ্য CA-এর মধ্যে CA-এর সেট সীমাবদ্ধ করা।
- সিস্টেমে অন্তর্ভুক্ত নয় অতিরিক্ত CA-কে বিশ্বাস করা।
ডিফল্টরূপে, সমস্ত অ্যাপ থেকে সুরক্ষিত সংযোগগুলি (TLS এবং HTTPS-এর মতো প্রোটোকল ব্যবহার করে) আগে থেকে ইনস্টল করা সিস্টেম CA-কে বিশ্বাস করে এবং Android 6.0 (API লেভেল 23) এবং নিম্নতর অ্যাপ্লিকেশানগুলিকে লক্ষ্য করে ডিফল্টভাবে ব্যবহারকারী-যুক্ত CA স্টোরকেও বিশ্বাস করে৷ আপনি base-config
(অ্যাপ-ওয়াইড কাস্টমাইজেশনের জন্য) বা domain-config
(প্রতি-ডোমেন কাস্টমাইজেশনের জন্য) ব্যবহার করে আপনার অ্যাপের সংযোগগুলি কাস্টমাইজ করতে পারেন।
একটি কাস্টম CA কনফিগার করুন
আপনি এমন একটি হোস্টের সাথে সংযোগ করতে চাইতে পারেন যা একটি স্ব-স্বাক্ষরিত SSL শংসাপত্র ব্যবহার করে বা এমন একটি হোস্টের সাথে যার SSL শংসাপত্র একটি অ-পাবলিক CA দ্বারা জারি করা হয় যা আপনি বিশ্বাস করেন, যেমন আপনার কোম্পানির অভ্যন্তরীণ CA৷ নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ একটি কাস্টম CA-এর জন্য কীভাবে আপনার অ্যাপ কনফিগার করবেন তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/my_ca
তে PEM বা DER ফর্ম্যাটে স্ব-স্বাক্ষরিত বা অ-সর্বজনীন CA শংসাপত্র যোগ করুন।
বিশ্বস্ত CA-এর সেট সীমিত করুন
আপনি যদি না চান যে আপনার অ্যাপ সিস্টেমের দ্বারা বিশ্বস্ত সমস্ত CA-কে বিশ্বাস করুক, আপনি পরিবর্তে বিশ্বাস করার জন্য CA-এর একটি কম সেট নির্দিষ্ট করতে পারেন। এটি অন্য যেকোন CA দ্বারা জারি করা প্রতারণামূলক শংসাপত্র থেকে অ্যাপটিকে রক্ষা করে৷
বিশ্বস্ত CA-এর সেট সীমিত করার কনফিগারেশন একটি নির্দিষ্ট ডোমেনের জন্য একটি কাস্টম CA-কে বিশ্বাস করার অনুরূপ, রিসোর্সে একাধিক CA প্রদান করা ছাড়া। নিম্নলিখিত কোডের উদ্ধৃতিটি res/xml/network_security_config.xml
এ আপনার অ্যাপের বিশ্বস্ত CA-এর সেটকে কীভাবে সীমাবদ্ধ করতে হয় তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">secure.example.com</domain> <domain includeSubdomains="true">cdn.example.com</domain> <trust-anchors> <certificates src="@raw/trusted_roots"/> </trust-anchors> </domain-config> </network-security-config>
res/raw/trusted_roots
এ PEM বা DER ফর্ম্যাটে বিশ্বস্ত CA যোগ করুন। মনে রাখবেন যে আপনি যদি PEM ফর্ম্যাট ব্যবহার করেন তবে ফাইলটিতে শুধুমাত্র PEM ডেটা থাকতে হবে এবং কোনও অতিরিক্ত পাঠ্য থাকবে না। আপনি একটির পরিবর্তে একাধিক <certificates>
উপাদান প্রদান করতে পারেন।
অতিরিক্ত CA-কে বিশ্বাস করুন
আপনি আপনার অ্যাপটিকে অতিরিক্ত CA-কে বিশ্বাস করতে চাইতে পারেন যেগুলি সিস্টেমের দ্বারা বিশ্বাসযোগ্য নয়, যেমন যদি সিস্টেমটি এখনও CA অন্তর্ভুক্ত না করে বা CA Android সিস্টেমে অন্তর্ভুক্তির প্রয়োজনীয়তাগুলি পূরণ করে না৷ আপনি নিম্নলিখিত উদ্ধৃতির মতো কোড ব্যবহার করে res/xml/network_security_config.xml
এ কনফিগারেশনের জন্য একাধিক শংসাপত্র উত্স নির্দিষ্ট করতে পারেন।
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="@raw/extracas"/> <certificates src="system"/> </trust-anchors> </base-config> </network-security-config>
ডিবাগিংয়ের জন্য CA কনফিগার করুন
HTTPS-এর মাধ্যমে সংযোগকারী একটি অ্যাপ ডিবাগ করার সময়, আপনি একটি স্থানীয় ডেভেলপমেন্ট সার্ভারের সাথে সংযোগ করতে চাইতে পারেন যেখানে আপনার উৎপাদন সার্ভারের জন্য SSL শংসাপত্র নেই। আপনার অ্যাপের কোডে কোনো পরিবর্তন না করেই এটিকে সমর্থন করতে, আপনি debug-overrides
ব্যবহার করে শুধুমাত্র ডিবাগ-অনলি CAগুলি নির্দিষ্ট করতে পারেন, যেগুলি শুধুমাত্র তখনই বিশ্বস্ত হয় যখন android:debuggable true
হয়। সাধারণত, IDEs এবং বিল্ড টুলগুলি এই পতাকাটি অ-মুক্তি বিল্ডগুলির জন্য স্বয়ংক্রিয়ভাবে সেট করে।
এটি সাধারণ শর্তসাপেক্ষ কোডের চেয়ে নিরাপদ কারণ নিরাপত্তা সতর্কতা হিসাবে, অ্যাপ স্টোরগুলি ডিবাগযোগ্য হিসাবে চিহ্নিত অ্যাপগুলিকে গ্রহণ করে না৷
নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml
এ ডিবাগ-শুধুমাত্র CAগুলি নির্দিষ্ট করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <debug-overrides> <trust-anchors> <certificates src="@raw/debug_cas"/> </trust-anchors> </debug-overrides> </network-security-config>
শংসাপত্রের স্বচ্ছতা বেছে নিন
দ্রষ্টব্য: শংসাপত্র স্বচ্ছতা সমর্থন শুধুমাত্র Android 16 (API স্তর 36) থেকে উপলব্ধ।
সার্টিফিকেট ট্রান্সপারেন্সি (CT, RFC 6962 ) হল একটি ইন্টারনেট স্ট্যান্ডার্ড যা ডিজিটাল সার্টিফিকেটের নিরাপত্তা বাড়ানোর জন্য ডিজাইন করা হয়েছে। সার্টিফিকেট প্রদানের প্রক্রিয়ায় স্বচ্ছতা এবং জবাবদিহিতা বৃদ্ধি করে, CA-দের সমস্ত জারি করা শংসাপত্র একটি পাবলিক লগে জমা দিতে হবে যা তাদের রেকর্ড করে।
সমস্ত শংসাপত্রের একটি যাচাইযোগ্য রেকর্ড বজায় রাখার মাধ্যমে, CT দূষিত অভিনেতাদের জন্য শংসাপত্র জাল করা বা CA-এর জন্য ভুলভাবে সেগুলি জারি করাকে উল্লেখযোগ্যভাবে কঠিন করে তোলে৷ এটি ব্যবহারকারীদের ম্যান-ইন-দ্য-মিডল আক্রমণ এবং অন্যান্য নিরাপত্তা হুমকি থেকে রক্ষা করতে সহায়তা করে। আরও তথ্যের জন্য, transparency.dev- এর ব্যাখ্যা দেখুন। Android-এ CT সম্মতি সম্পর্কে আরও তথ্যের জন্য, Android এর CT নীতি দেখুন।
ডিফল্টরূপে, শংসাপত্রগুলি CT লগ-এ লগ-ইন করা হোক না কেন তা গ্রহণ করা হয়। আপনার অ্যাপটি শুধুমাত্র একটি CT লগ ইন করা শংসাপত্রের সাথে গন্তব্যের সাথে সংযোগ করছে তা নিশ্চিত করতে, আপনি বিশ্বব্যাপী বা প্রতি-ডোমেনের ভিত্তিতে বৈশিষ্ট্যটিতে অপ্ট ইন করতে পারেন৷
ক্লিয়ারটেক্সট ট্রাফিক অপ্ট আউট করুন
দ্রষ্টব্য: এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার নিচের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়।
আপনি যদি আপনার অ্যাপটি শুধুমাত্র সুরক্ষিত সংযোগ ব্যবহার করে গন্তব্যগুলির সাথে সংযোগ করতে চান, তাহলে আপনি সেই গন্তব্যগুলিতে সমর্থনকারী ক্লিয়ারটেক্সট (HTTPS এর পরিবর্তে এনক্রিপ্ট করা HTTP প্রোটোকল ব্যবহার করে) অপ্ট আউট করতে পারেন৷ এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উত্স দ্বারা প্রদত্ত URL গুলির পরিবর্তনের কারণে অ্যাপগুলিতে দুর্ঘটনাজনিত রিগ্রেশন প্রতিরোধ করতে সহায়তা করে৷ আরও বিস্তারিত জানার জন্য NetworkSecurityPolicy.isCleartextTrafficPermitted()
দেখুন।
উদাহরণ স্বরূপ, আপনি আপনার অ্যাপটি নিশ্চিত করতে চাইতে পারেন যে secure.example.com
এর সাথে সংযোগগুলি সর্বদা HTTPS-এর মাধ্যমে প্রতিকূল নেটওয়ার্কগুলি থেকে সংবেদনশীল ট্র্যাফিককে সুরক্ষিত করতে হবে৷
নীচের উদ্ধৃতিটি দেখায় কিভাবে res/xml/network_security_config.xml
এ ক্লিয়ারটেক্সট থেকে অপ্ট আউট করতে হয়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </network-security-config>
পিন সার্টিফিকেট
সাধারণত, একটি অ্যাপ সমস্ত প্রাক-ইনস্টল করা CAগুলিকে বিশ্বাস করে৷ যদি এই CA-এর মধ্যে কেউ একটি জালিয়াতি শংসাপত্র জারি করে, তাহলে অ্যাপটি অন-পাথ আক্রমণকারীর থেকে ঝুঁকিতে থাকবে। কিছু অ্যাপ্লিকেশান তাদের বিশ্বাসযোগ্য CA-এর সেট সীমিত করে বা শংসাপত্র পিনিংয়ের মাধ্যমে তাদের গ্রহণযোগ্য শংসাপত্রের সেট সীমিত করতে বেছে নেয়।
সার্টিফিকেট পিনিং পাবলিক কী (X.509 সার্টিফিকেটের SubjectPublicKeyInfo
) হ্যাশের মাধ্যমে সার্টিফিকেটের একটি সেট প্রদান করে করা হয়। একটি শংসাপত্র চেইন তখনই বৈধ হয় যদি শংসাপত্রের চেইনে কমপক্ষে একটি পিন করা পাবলিক কী থাকে৷
মনে রাখবেন, শংসাপত্রের পিনিং ব্যবহার করার সময়, আপনার সর্বদা একটি ব্যাকআপ কী অন্তর্ভুক্ত করা উচিত যাতে আপনি যদি নতুন কীগুলিতে স্যুইচ করতে বা সিএএস পরিবর্তন করতে বাধ্য হন (যখন কোনও সিএ শংসাপত্র বা সেই সিএর মধ্যবর্তী সময়ে পিন করার সময়), আপনার অ্যাপ্লিকেশনটির সংযোগটি প্রভাবিত না। অন্যথায়, সংযোগ পুনরুদ্ধার করতে আপনাকে অবশ্যই অ্যাপ্লিকেশনটিতে একটি আপডেট চাপিয়ে দিতে হবে।
অতিরিক্তভাবে, পিনগুলির জন্য পিনিং সম্পাদন করা হয় না তার জন্য একটি মেয়াদোত্তীর্ণ সময় নির্ধারণ করা সম্ভব। এটি আপডেট করা হয়নি এমন অ্যাপ্লিকেশনগুলিতে সংযোগের সমস্যাগুলি প্রতিরোধে সহায়তা করে। যাইহোক, পিনগুলিতে মেয়াদোত্তীর্ণ সময় নির্ধারণ করা আক্রমণকারীদের আপনার পিনযুক্ত শংসাপত্রগুলি বাইপাস করতে সক্ষম করতে পারে।
নীচের অংশটি কীভাবে res/xml/network_security_config.xml
-এ শংসাপত্রগুলি পিন করতে হবে তা দেখায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin> <!-- backup pin --> <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config>
কনফিগারেশন উত্তরাধিকার আচরণ
নির্দিষ্ট কনফিগারেশনে সেট করা মানগুলি উত্তরাধিকার সূত্রে প্রাপ্ত হয়। কনফিগারেশন ফাইলটি পঠনযোগ্য রাখার সময় এই আচরণটি আরও জটিল কনফিগারেশনের অনুমতি দেয়।
উদাহরণস্বরূপ, domain-config
সেট করা মানগুলি পিতামাতার domain-config
থেকে নেওয়া হয়, যদি বাসা হয়, বা base-config
থেকে, যদি না হয়। base-config
সেট করা মানগুলি প্ল্যাটফর্ম ডিফল্ট মানগুলি ব্যবহার করে।
উদাহরণস্বরূপ, এমন একটি কেস বিবেচনা করুন যেখানে example.com
সাবডোমেনগুলির সমস্ত সংযোগ অবশ্যই সিএএসের একটি কাস্টম সেট ব্যবহার করতে হবে। অতিরিক্তভাবে, এই ডোমেনগুলিতে secure.example.com
ট্র্যাফিকের অনুমতি দেওয়া হয় seckecte example.com
কনফিগারেশনের অভ্যন্তরে secure.example.com
জন্য কনফিগারেশনটি বাসা বাঁধার মাধ্যমে, trust-anchors
নকল করার দরকার নেই।
নীচের অংশটি দেখায় যে এই বাসা কীভাবে res/xml/network_security_config.xml
-এ দেখবে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </domain-config> </network-security-config>
কনফিগারেশন ফাইল ফরম্যাট
নেটওয়ার্ক সুরক্ষা কনফিগারেশন বৈশিষ্ট্যটি একটি এক্সএমএল ফাইল ফর্ম্যাট ব্যবহার করে। ফাইলের সামগ্রিক কাঠামো নিম্নলিখিত কোড নমুনায় দেখানো হয়েছে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </base-config> <domain-config> <domain>android.com</domain> ... <trust-anchors> <certificates src="..."/> ... </trust-anchors> <pin-set> <pin digest="...">...</pin> ... </pin-set> </domain-config> ... <debug-overrides> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </debug-overrides> </network-security-config>
নিম্নলিখিত বিভাগগুলি ফাইল ফর্ম্যাটের সিনট্যাক্স এবং অন্যান্য বিশদ বর্ণনা করে।
<network-security-config>
- থাকতে পারে:
- 0 বা 1 এর
<base-config>
>
যে কোনও সংখ্যক<domain-config>
0 বা 1 এর<debug-overrides>
>
<বেস-কনফিগেশন>
- সিনট্যাক্স:
<base-config cleartextTrafficPermitted=["true" | "false"]> ... </base-config>
- থাকতে পারে:
-
<trust-anchors>
অ্যাঙ্কারস><certificateTransparency>
- বর্ণনা:
- সমস্ত সংযোগ দ্বারা ব্যবহৃত ডিফল্ট কনফিগারেশন যার গন্তব্য কোনও
domain-config
দ্বারা আচ্ছাদিত নয়।সেট করা নেই এমন কোনও মান প্ল্যাটফর্ম ডিফল্ট মান ব্যবহার করে।
অ্যান্ড্রয়েড 9 (এপিআই স্তর 28) এবং আরও উচ্চতর অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) কে অ্যান্ড্রয়েড 8.1 (এপিআই স্তর 27) লক্ষ্য করে অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) এবং লোয়ারকে লক্ষ্য করে অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config>
<domain-config>
- সিনট্যাক্স:
<domain-config cleartextTrafficPermitted=["true" | "false"]> ... </domain-config>
- থাকতে পারে:
- 1 বা আরও
<domain>
0 বা 1<certificateTransparency>
>
0 বা 1<trust-anchors>
>
0 বা 1<pin-set>
সেট>
নেস্টেডের যে কোনও সংখ্যা<domain-config>
- বর্ণনা:
-
domain
উপাদানগুলির দ্বারা সংজ্ঞায়িত হিসাবে নির্দিষ্ট গন্তব্যগুলির সংযোগের জন্য ব্যবহৃত কনফিগারেশন।মনে রাখবেন যে যদি একাধিক
domain-config
উপাদানগুলি কোনও গন্তব্যকে কভার করে তবে সর্বাধিক নির্দিষ্ট (দীর্ঘতম) ম্যাচিং ডোমেন নিয়মের সাথে কনফিগারেশনটি ব্যবহৃত হয়।
<ডোমেইন>
- সিনট্যাক্স:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
- গুণাবলী:
-
includeSubdomains
- যদি
"true"
হয় তবে এই ডোমেন নিয়মটি ডোমেন এবং সমস্ত সাবডোমেনগুলির সাথে সাবডোমেনগুলির সাবডোমেন সহ মেলে। অন্যথায়, নিয়মটি কেবল সঠিক ম্যাচগুলিতে প্রযোজ্য।
-
<সার্টিফিকেটট্রান্সপ্রেসেন্সি>
- সিনট্যাক্স:
<certificateTransparency enabled=["true" | "false"]/>
- বর্ণনা:
- যদি
true
, তবে অ্যাপ্লিকেশনটি শংসাপত্রগুলি যাচাই করতে শংসাপত্রের স্বচ্ছ লগগুলি ব্যবহার করবে। যখন কোনও অ্যাপ্লিকেশন তার নিজস্ব শংসাপত্র (বা ব্যবহারকারী স্টোর) ব্যবহার করে, সম্ভবত শংসাপত্রটি সর্বজনীন নয় এবং তাই শংসাপত্রের স্বচ্ছতা ব্যবহার করে যাচাইযোগ্য নয়। ডিফল্টরূপে, এই ক্ষেত্রেগুলির জন্য যাচাইকরণ অক্ষম করা হয়। ডোমেন কনফিগারেশনে<certificateTransparency enabled="true"/>
ব্যবহার করে যাচাইকরণ জোর করা এখনও সম্ভব। প্রতিটি<domain-config>
এর জন্য, মূল্যায়ন এই আদেশটি অনুসরণ করে:- যদি
certificateTransparency
সক্ষম করা থাকে তবে যাচাইকরণ সক্ষম করুন। - যদি কোনও
<trust-anchors>
"user"
বা ইনলাইন (অর্থাত্,"@raw/cert.pem"
) হয় তবে যাচাইকরণটি অক্ষম করুন। - অন্যথায়, উত্তরাধিকার সূত্রে প্রাপ্ত কনফিগারেশনের উপর নির্ভর করুন।
- যদি
<ডিবাগ-ওভাররিডস>
- সিনট্যাক্স:
<debug-overrides> ... </debug-overrides>
- থাকতে পারে:
- 0 বা 1
<trust-anchors>
> - বর্ণনা:
- অ্যান্ড্রয়েড: ডিবাগেবল যখন
"true"
হয় তখন ওভাররাইডগুলি প্রয়োগ করা হবে, যা সাধারণত আইডিই এবং বিল্ড সরঞ্জামগুলি দ্বারা উত্পাদিত অ-রিলিজ বিল্ডগুলির ক্ষেত্রে হয়।debug-overrides
নির্দিষ্ট ট্রাস্ট অ্যাঙ্করগুলি অন্যান্য সমস্ত কনফিগারেশনে যুক্ত করা হয় এবং সার্ভারের শংসাপত্র চেইন এই ডিবাগ-কেবলমাত্র বিশ্বাসের অ্যাঙ্করগুলির মধ্যে একটি ব্যবহার করে যখন শংসাপত্রের পিনিং করা হয় না। যদি অ্যান্ড্রয়েড: ডিবাগেবল"false"
হয় তবে এই বিভাগটি সম্পূর্ণ উপেক্ষা করা হয়েছে।
<ট্রাস্ট-অ্যাঙ্কর>
- সিনট্যাক্স:
<trust-anchors> ... </trust-anchors>
- থাকতে পারে:
-
<certificates>
এর যে কোনও সংখ্যা - বর্ণনা:
- সুরক্ষিত সংযোগের জন্য ট্রাস্ট অ্যাঙ্করগুলির সেট।
<শংসাপত্র>
- সিনট্যাক্স:
<certificates src=["system" | "user" | "raw resource"] overridePins=["true" | "false"] />
- বর্ণনা:
-
trust-anchors
উপাদানগুলির জন্য x.509 শংসাপত্রের সেট। - গুণাবলী:
-
src
- সিএ শংসাপত্রের উত্স। প্রতিটি শংসাপত্র নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
- x.509 শংসাপত্রযুক্ত একটি ফাইলের দিকে নির্দেশ করে একটি কাঁচা রিসোর্স আইডি। শংসাপত্রগুলি অবশ্যই ডিইআর বা পিইএম ফর্ম্যাটে এনকোড করা উচিত। পিইএম শংসাপত্রের ক্ষেত্রে, ফাইলটিতে অবশ্যই অতিরিক্ত নন-পিইএম ডেটা যেমন মন্তব্য রয়েছে না ।
- প্রাক-ইনস্টল সিস্টেম সিএ শংসাপত্রগুলির জন্য
"system"
- ব্যবহারকারী-যুক্ত সিএ শংসাপত্রের জন্য
"user"
-
overridePins
এই উত্স বাইপাস শংসাপত্রের পিনিং থেকে সিএএস যদি নির্দিষ্ট করে। যদি
"true"
, তবে পিনিং শংসাপত্রের চেইনে সঞ্চালিত হয় না যা এই উত্স থেকে সিএগুলির মধ্যে একটি স্বাক্ষরিত। এটি সিএএস ডিবাগিং করার জন্য বা আপনার অ্যাপের সুরক্ষিত ট্র্যাফিকের মধ্যে ম্যান-ইন-দ্য-মধ্য আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।ডিফল্ট
"false"
যদি না কোনওdebug-overrides
উপাদানগুলিতে নির্দিষ্ট না করা হয়, সেক্ষেত্রে ডিফল্টটি"true"
হয়।
-
<পিন-সেট>
- সিনট্যাক্স:
<pin-set expiration="date"> ... </pin-set>
- থাকতে পারে:
-
<pin>
এর যে কোনও সংখ্যা - বর্ণনা:
- পাবলিক কী পিনের একটি সেট। সুরক্ষিত সংযোগটি বিশ্বাসযোগ্য হওয়ার জন্য, চেইন অফ ট্রাস্টের অন্যতম পাবলিক কীগুলি অবশ্যই পিনের সেটে থাকতে হবে। পিনের ফর্ম্যাটের জন্য
<pin>
দেখুন। - গুণাবলী:
-
expiration
- তারিখটি,
yyyy-MM-dd
ফর্ম্যাটে, যার উপর পিনগুলি শেষ হয়, এইভাবে পিনিং অক্ষম করে। যদি বৈশিষ্ট্যটি সেট না করা থাকে তবে পিনের মেয়াদ শেষ হয় না।মেয়াদোত্তীর্ণতা অ্যাপ্লিকেশনগুলিতে সংযোগের সমস্যাগুলি প্রতিরোধে সহায়তা করে যা তাদের পিন সেটে আপডেটগুলি পায় না, যেমন ব্যবহারকারী যখন অ্যাপ্লিকেশন আপডেটগুলি অক্ষম করে।
-
<পিন>
- সিনট্যাক্স:
<pin digest=["SHA-256"]>base64 encoded digest of X.509 SubjectPublicKeyInfo (SPKI)</pin>
- গুণাবলী:
-
digest
- ডাইজেস্ট অ্যালগরিদম পিন তৈরি করতে ব্যবহৃত হয়। বর্তমানে, কেবল
"SHA-256"
সমর্থিত।
-
নেটওয়ার্ক সুরক্ষা কনফিগারেশন বৈশিষ্ট্যটি আপনাকে অ্যাপ্লিকেশন কোডটি সংশোধন না করে একটি নিরাপদ, ঘোষণামূলক কনফিগারেশন ফাইলে আপনার অ্যাপের নেটওয়ার্ক সুরক্ষা সেটিংস কাস্টমাইজ করতে দেয়। এই সেটিংস নির্দিষ্ট ডোমেন এবং একটি নির্দিষ্ট অ্যাপের জন্য কনফিগার করা যেতে পারে। এই বৈশিষ্ট্যটির মূল ক্ষমতাগুলি হ'ল:
- কাস্টম ট্রাস্ট অ্যাঙ্কর: কোন শংসাপত্র কর্তৃপক্ষ (সিএ) কোনও অ্যাপের সুরক্ষিত সংযোগের জন্য বিশ্বাসযোগ্য তা কাস্টমাইজ করুন। উদাহরণস্বরূপ, নির্দিষ্ট স্ব-স্বাক্ষরিত শংসাপত্রগুলিকে বিশ্বাস করা বা অ্যাপ্লিকেশনটি বিশ্বাস করে এমন পাবলিক সিএগুলির সেটকে সীমাবদ্ধ করে।
- ডিবাগ-কেবল ওভাররাইডস: ইনস্টল করা বেসে ঝুঁকি ছাড়াই কোনও অ্যাপ্লিকেশনটিতে নিরাপদে সুরক্ষিত সংযোগগুলি নিরাপদে ডিবাগ করুন।
- ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট: ক্লিয়ারটেক্সট (আনক্রিপ্টেড) ট্র্যাফিকের দুর্ঘটনাজনিত ব্যবহার থেকে অ্যাপ্লিকেশনগুলিকে রক্ষা করুন।
- শংসাপত্র স্বচ্ছতা অপ্ট-ইন: যথাযথ লগ করা শংসাপত্রগুলি ব্যবহার করতে একটি অ্যাপের সুরক্ষিত সংযোগগুলি সীমাবদ্ধ করুন।
- শংসাপত্র পিনিং: নির্দিষ্ট শংসাপত্রগুলির সাথে কোনও অ্যাপের সুরক্ষিত সংযোগ সীমাবদ্ধ করুন।
একটি নেটওয়ার্ক সুরক্ষা কনফিগারেশন ফাইল যুক্ত করুন
নেটওয়ার্ক সুরক্ষা কনফিগারেশন বৈশিষ্ট্যটি একটি এক্সএমএল ফাইল ব্যবহার করে যেখানে আপনি আপনার অ্যাপ্লিকেশনটির জন্য সেটিংস নির্দিষ্ট করেন। এই ফাইলটি নির্দেশ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে একটি এন্ট্রি অন্তর্ভুক্ত করতে হবে। ম্যানিফেস্ট থেকে নিম্নলিখিত কোডের অংশগুলি কীভাবে এই এন্ট্রি তৈরি করবেন তা প্রমাণ করে:
<?xml version="1.0" encoding="utf-8"?> <manifest ... > <application android:networkSecurityConfig="@xml/network_security_config" ... > ... </application> </manifest>
বিশ্বস্ত সিএএস কাস্টমাইজ করুন
আপনি চাইতে পারেন আপনার অ্যাপ্লিকেশনটি প্ল্যাটফর্ম ডিফল্টের পরিবর্তে সিএএসের একটি কাস্টম সেটকে বিশ্বাস করতে পারে। এর জন্য সবচেয়ে সাধারণ কারণগুলি হল:
- একটি কাস্টম সিএর সাথে হোস্টের সাথে সংযোগ স্থাপন করা, যেমন একটি সিএ যা স্ব-স্বাক্ষরিত বা কোনও সংস্থার মধ্যে অভ্যন্তরীণভাবে জারি করা হয়।
- প্রতিটি প্রাক ইনস্টলড সিএর পরিবর্তে আপনি যে সিএএসের উপর নির্ভর করেন কেবল সিএএসের সেটকে সীমাবদ্ধ করা
- সিস্টেমে অন্তর্ভুক্ত নয় অতিরিক্ত সিএএসকে বিশ্বাস করা।
ডিফল্টরূপে, সমস্ত অ্যাপ্লিকেশন থেকে সুরক্ষিত সংযোগগুলি (টিএলএস এবং এইচটিটিপিএসের মতো প্রোটোকল ব্যবহার করে) প্রাক-ইনস্টলড সিস্টেম সিএএসকে বিশ্বাস করে এবং অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) লক্ষ্য করে অ্যাপ্লিকেশনগুলি ডিফল্টরূপে ব্যবহারকারী-যুক্ত সিএ স্টোরকেও বিশ্বাস করে। আপনি base-config
(অ্যাপ-ওয়াইড কাস্টমাইজেশনের জন্য) বা domain-config
(প্রতি ডোমেন কাস্টমাইজেশনের জন্য) ব্যবহার করে আপনার অ্যাপ্লিকেশনটির সংযোগগুলি কাস্টমাইজ করতে পারেন।
একটি কাস্টম সিএ কনফিগার করুন
আপনি এমন কোনও হোস্টের সাথে সংযোগ স্থাপন করতে চাইতে পারেন যা স্ব-স্বাক্ষরিত এসএসএল শংসাপত্র ব্যবহার করে বা এমন কোনও হোস্টের কাছে যার এসএসএল শংসাপত্রটি আপনার বিশ্বাস করেন এমন একটি অ-পাবলিক সিএ দ্বারা জারি করা হয়, যেমন আপনার সংস্থার অভ্যন্তরীণ সিএ। নিম্নলিখিত কোডের অংশটি কীভাবে res/xml/network_security_config.xml
-এ কাস্টম সিএর জন্য আপনার অ্যাপটি কনফিগার করবেন তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> </domain-config> </network-security-config>
PEM বা DER ফর্ম্যাটে স্ব-স্বাক্ষরিত বা অ-পাবলিক সিএ শংসাপত্র যুক্ত করুন res/raw/my_ca
এ।
বিশ্বস্ত সিএএসের সেট সীমাবদ্ধ করুন
আপনি যদি চান না যে আপনার অ্যাপ্লিকেশনটি সিস্টেমের দ্বারা বিশ্বাসযোগ্য সমস্ত সিএএসকে বিশ্বাস করতে পারে তবে আপনি পরিবর্তে সিএএসের একটি হ্রাস সেটকে বিশ্বাসের জন্য নির্দিষ্ট করতে পারেন। এটি অ্যাপ্লিকেশনটিকে অন্য কোনও সিএএস দ্বারা জারি করা জালিয়াতি শংসাপত্রগুলি থেকে রক্ষা করে।
বিশ্বস্ত সিএএসের সেটকে সীমাবদ্ধ করার কনফিগারেশনটি নির্দিষ্ট ডোমেনের জন্য একটি কাস্টম সিএকে বিশ্বাস করার অনুরূপ যা একাধিক সিএএস সংস্থানটিতে সরবরাহ করা হয়। নিম্নলিখিত কোডের অংশটি কীভাবে আপনার অ্যাপ্লিকেশনটির বিশ্বস্ত সিএএসের সেটকে res/xml/network_security_config.xml
-তে সীমাবদ্ধ করতে পারে তা প্রদর্শন করে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">secure.example.com</domain> <domain includeSubdomains="true">cdn.example.com</domain> <trust-anchors> <certificates src="@raw/trusted_roots"/> </trust-anchors> </domain-config> </network-security-config>
পিইএম বা ডের ফর্ম্যাটে বিশ্বস্ত সিএএস যুক্ত করুন res/raw/trusted_roots
। মনে রাখবেন যে আপনি যদি পিইএম ফর্ম্যাট ব্যবহার করেন তবে ফাইলটিতে অবশ্যই কেবল পিইএম ডেটা এবং কোনও অতিরিক্ত পাঠ্য থাকতে হবে। আপনি একটির পরিবর্তে একাধিক <certificates>
উপাদান সরবরাহ করতে পারেন।
অতিরিক্ত সিএএস বিশ্বাস করুন
আপনি চাইতে পারেন যে আপনার অ্যাপ্লিকেশনটি অতিরিক্ত সিএএস -কে বিশ্বাস করতে পারে যা সিস্টেমের দ্বারা বিশ্বাসযোগ্য নয়, যেমন সিস্টেমটি এখনও সিএ অন্তর্ভুক্ত না করে বা সিএ অ্যান্ড্রয়েড সিস্টেমে অন্তর্ভুক্তির প্রয়োজনীয়তাগুলি পূরণ করে না। আপনি নিম্নলিখিত অংশের মতো কোড ব্যবহার করে res/xml/network_security_config.xml
-তে একটি কনফিগারেশনের জন্য একাধিক শংসাপত্রের উত্স নির্দিষ্ট করতে পারেন।
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="@raw/extracas"/> <certificates src="system"/> </trust-anchors> </base-config> </network-security-config>
ডিবাগিংয়ের জন্য সিএএস কনফিগার করুন
এইচটিটিপিএসের সাথে সংযোগ স্থাপনকারী কোনও অ্যাপ্লিকেশন ডিবাগ করার সময়, আপনি এমন কোনও স্থানীয় বিকাশ সার্ভারের সাথে সংযোগ করতে চাইতে পারেন যা আপনার প্রোডাকশন সার্ভারের জন্য এসএসএল শংসাপত্র নেই। আপনার অ্যাপের কোডে কোনও পরিবর্তন ছাড়াই এটিকে সমর্থন করার জন্য, আপনি কেবলমাত্র debug-overrides
ব্যবহার করে অ্যান্ড্রয়েড: ডিবাগেবল true
যখন বিশ্বাসযোগ্য তখনই ডিবাগ-কেবল সিএএস নির্দিষ্ট করতে পারেন। সাধারণত, আইডিই এবং বিল্ড সরঞ্জামগুলি অ-রিলিজ বিল্ডগুলির জন্য স্বয়ংক্রিয়ভাবে এই পতাকাটি সেট করে।
এটি সাধারণ শর্তসাপেক্ষ কোডের চেয়ে নিরাপদ কারণ সুরক্ষা সতর্কতা হিসাবে অ্যাপ স্টোরগুলি ডিবাগেবল হিসাবে চিহ্নিত অ্যাপ্লিকেশনগুলি গ্রহণ করে না।
নীচের অংশটি দেখায় যে কীভাবে res/xml/network_security_config.xml
এ ডিবাগ-কেবল সিএএস নির্দিষ্ট করা যায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <debug-overrides> <trust-anchors> <certificates src="@raw/debug_cas"/> </trust-anchors> </debug-overrides> </network-security-config>
স্বচ্ছতার শংসাপত্র বেছে নিন
দ্রষ্টব্য: শংসাপত্রের স্বচ্ছতা সমর্থন কেবল অ্যান্ড্রয়েড 16 (এপিআই স্তর 36) থেকে পাওয়া যায়।
শংসাপত্র স্বচ্ছতা (সিটি, আরএফসি 6962 ) একটি ইন্টারনেট স্ট্যান্ডার্ড যা ডিজিটাল শংসাপত্রগুলির সুরক্ষা বাড়ানোর জন্য ডিজাইন করা হয়েছে। শংসাপত্র প্রদানের প্রক্রিয়াতে স্বচ্ছতা এবং জবাবদিহিতা বৃদ্ধি করে এমন একটি পাবলিক লগকে তাদের রেকর্ড করা সমস্ত জারি করা শংসাপত্র জমা দেওয়ার জন্য সিএএসের প্রয়োজন।
সমস্ত শংসাপত্রের যাচাইযোগ্য রেকর্ড বজায় রেখে, সিটি দূষিত অভিনেতাদের পক্ষে শংসাপত্র তৈরি করা বা সিএএসের ভুল করে সেগুলি জারি করা উল্লেখযোগ্যভাবে আরও শক্ত করে তোলে। এটি ব্যবহারকারীদের মধ্য-মধ্যম আক্রমণ এবং অন্যান্য সুরক্ষা হুমকির হাত থেকে রক্ষা করতে সহায়তা করে। আরও তথ্যের জন্য, স্বচ্ছতার উপর ব্যাখ্যা দেখুন। অ্যান্ড্রয়েডে সিটি সম্মতি সম্পর্কে আরও তথ্যের জন্য, অ্যান্ড্রয়েডের সিটি নীতি দেখুন।
ডিফল্টরূপে, শংসাপত্রগুলি কোনও সিটি লগে লগইন করা হয়েছে কিনা তা নির্বিশেষে গৃহীত হয়। আপনার অ্যাপ্লিকেশনটি কেবল সিটি লগে লগ ইন করা শংসাপত্রগুলির সাথে গন্তব্যগুলির সাথে সংযোগ স্থাপন করে তা নিশ্চিত করতে, আপনি বিশ্বব্যাপী বা প্রতি ডোমেন ভিত্তিতে বৈশিষ্ট্যটি বেছে নিতে পারেন।
ক্লিয়ারটেক্সট ট্র্যাফিক থেকে বেরিয়ে আসা
দ্রষ্টব্য: এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার নিচের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়।
আপনি যদি কেবল সুরক্ষিত সংযোগগুলি ব্যবহার করে গন্তব্যগুলির সাথে সংযোগ স্থাপনের জন্য আপনার অ্যাপ্লিকেশনটির ইচ্ছা পোষণ করেন তবে আপনি সেই গন্তব্যগুলিতে ক্লিয়ারটেক্সট (এইচটিটিপিএসের পরিবর্তে এনক্রিপ্টড এইচটিটিপি প্রোটোকল ব্যবহার করে) সমর্থন করে বেছে নিতে পারেন। এই বিকল্পটি ব্যাকএন্ড সার্ভারগুলির মতো বাহ্যিক উত্স দ্বারা সরবরাহিত ইউআরএল পরিবর্তনের কারণে অ্যাপ্লিকেশনগুলিতে দুর্ঘটনাজনিত রিগ্রেশনগুলি রোধ করতে সহায়তা করে। আরও তথ্যের জন্য NetworkSecurityPolicy.isCleartextTrafficPermitted()
দেখুন।
উদাহরণস্বরূপ, আপনি আপনার অ্যাপ্লিকেশনটি নিশ্চিত করতে পারেন যে সংযোগগুলি secure.example.com
করার জন্য।
নীচের অংশটি দেখায় যে কীভাবে res/xml/network_security_config.xml
-এ ক্লিয়ারটেক্সট থেকে বেরিয়ে যেতে হবে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </network-security-config>
পিন শংসাপত্র
সাধারণত, একটি অ্যাপ্লিকেশন সমস্ত প্রাক ইনস্টলড সিএএসকে বিশ্বাস করে। যদি এই সিএগুলির মধ্যে কোনও জালিয়াতি শংসাপত্র জারি করা হয় তবে অ্যাপ্লিকেশনটি অন-পাথ আক্রমণকারী থেকে ঝুঁকির মধ্যে থাকবে। কিছু অ্যাপ্লিকেশন তারা বিশ্বাস করে যে সিএএসের সেটগুলি সীমাবদ্ধ করে বা শংসাপত্রের পিনিং দ্বারা সীমাবদ্ধ করে তারা যে শংসাপত্রগুলি গ্রহণ করে তার সেট সীমাবদ্ধ করতে পছন্দ করে।
শংসাপত্র পিনিং পাবলিক কী (x.509 শংসাপত্রের SubjectPublicKeyInfo
) দ্বারা হ্যাশ দ্বারা শংসাপত্রের একটি সেট সরবরাহ করে করা হয়। একটি শংসাপত্র শৃঙ্খলা তখনই বৈধ হয় যখন শংসাপত্র চেইনে কমপক্ষে পিনযুক্ত পাবলিক কীগুলির মধ্যে একটি থাকে।
মনে রাখবেন, শংসাপত্রের পিনিং ব্যবহার করার সময়, আপনার সর্বদা একটি ব্যাকআপ কী অন্তর্ভুক্ত করা উচিত যাতে আপনি যদি নতুন কীগুলিতে স্যুইচ করতে বা সিএএস পরিবর্তন করতে বাধ্য হন (যখন কোনও সিএ শংসাপত্র বা সেই সিএর মধ্যবর্তী সময়ে পিন করার সময়), আপনার অ্যাপ্লিকেশনটির সংযোগটি প্রভাবিত না। অন্যথায়, সংযোগ পুনরুদ্ধার করতে আপনাকে অবশ্যই অ্যাপ্লিকেশনটিতে একটি আপডেট চাপিয়ে দিতে হবে।
অতিরিক্তভাবে, পিনগুলির জন্য পিনিং সম্পাদন করা হয় না তার জন্য একটি মেয়াদোত্তীর্ণ সময় নির্ধারণ করা সম্ভব। এটি আপডেট করা হয়নি এমন অ্যাপ্লিকেশনগুলিতে সংযোগের সমস্যাগুলি প্রতিরোধে সহায়তা করে। যাইহোক, পিনগুলিতে মেয়াদোত্তীর্ণ সময় নির্ধারণ করা আক্রমণকারীদের আপনার পিনযুক্ত শংসাপত্রগুলি বাইপাস করতে সক্ষম করতে পারে।
নীচের অংশটি কীভাবে res/xml/network_security_config.xml
-এ শংসাপত্রগুলি পিন করতে হবে তা দেখায়:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin> <!-- backup pin --> <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config>
কনফিগারেশন উত্তরাধিকার আচরণ
নির্দিষ্ট কনফিগারেশনে সেট করা মানগুলি উত্তরাধিকার সূত্রে প্রাপ্ত হয়। কনফিগারেশন ফাইলটি পঠনযোগ্য রাখার সময় এই আচরণটি আরও জটিল কনফিগারেশনের অনুমতি দেয়।
উদাহরণস্বরূপ, domain-config
সেট করা মানগুলি পিতামাতার domain-config
থেকে নেওয়া হয়, যদি বাসা হয়, বা base-config
থেকে, যদি না হয়। base-config
সেট করা মানগুলি প্ল্যাটফর্ম ডিফল্ট মানগুলি ব্যবহার করে।
উদাহরণস্বরূপ, এমন একটি কেস বিবেচনা করুন যেখানে example.com
সাবডোমেনগুলির সমস্ত সংযোগ অবশ্যই সিএএসের একটি কাস্টম সেট ব্যবহার করতে হবে। অতিরিক্তভাবে, এই ডোমেনগুলিতে secure.example.com
ট্র্যাফিকের অনুমতি দেওয়া হয় seckecte example.com
কনফিগারেশনের অভ্যন্তরে secure.example.com
জন্য কনফিগারেশনটি বাসা বাঁধার মাধ্যমে, trust-anchors
নকল করার দরকার নেই।
নীচের অংশটি দেখায় যে এই বাসা কীভাবে res/xml/network_security_config.xml
-এ দেখবে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </domain-config> </network-security-config>
কনফিগারেশন ফাইল ফরম্যাট
নেটওয়ার্ক সুরক্ষা কনফিগারেশন বৈশিষ্ট্যটি একটি এক্সএমএল ফাইল ফর্ম্যাট ব্যবহার করে। ফাইলের সামগ্রিক কাঠামো নিম্নলিখিত কোড নমুনায় দেখানো হয়েছে:
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </base-config> <domain-config> <domain>android.com</domain> ... <trust-anchors> <certificates src="..."/> ... </trust-anchors> <pin-set> <pin digest="...">...</pin> ... </pin-set> </domain-config> ... <debug-overrides> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </debug-overrides> </network-security-config>
নিম্নলিখিত বিভাগগুলি ফাইল ফর্ম্যাটের সিনট্যাক্স এবং অন্যান্য বিশদ বর্ণনা করে।
<network-security-config>
- থাকতে পারে:
- 0 বা 1 এর
<base-config>
>
যে কোনও সংখ্যক<domain-config>
0 বা 1 এর<debug-overrides>
>
<বেস-কনফিগেশন>
- সিনট্যাক্স:
<base-config cleartextTrafficPermitted=["true" | "false"]> ... </base-config>
- থাকতে পারে:
-
<trust-anchors>
অ্যাঙ্কারস><certificateTransparency>
- বর্ণনা:
- সমস্ত সংযোগ দ্বারা ব্যবহৃত ডিফল্ট কনফিগারেশন যার গন্তব্য কোনও
domain-config
দ্বারা আচ্ছাদিত নয়।সেট করা নেই এমন কোনও মান প্ল্যাটফর্ম ডিফল্ট মান ব্যবহার করে।
অ্যান্ড্রয়েড 9 (এপিআই স্তর 28) এবং আরও উচ্চতর অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) কে অ্যান্ড্রয়েড 8.1 (এপিআই স্তর 27) লক্ষ্য করে অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config>
অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) এবং লোয়ারকে লক্ষ্য করে অ্যাপ্লিকেশনগুলির জন্য ডিফল্ট কনফিগারেশন নিম্নরূপ:
<base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config>
<domain-config>
- সিনট্যাক্স:
<domain-config cleartextTrafficPermitted=["true" | "false"]> ... </domain-config>
- থাকতে পারে:
- 1 বা আরও
<domain>
0 বা 1<certificateTransparency>
>
0 বা 1<trust-anchors>
>
0 বা 1<pin-set>
সেট>
নেস্টেডের যে কোনও সংখ্যা<domain-config>
- বর্ণনা:
-
domain
উপাদানগুলির দ্বারা সংজ্ঞায়িত হিসাবে নির্দিষ্ট গন্তব্যগুলির সংযোগের জন্য ব্যবহৃত কনফিগারেশন।মনে রাখবেন যে যদি একাধিক
domain-config
উপাদানগুলি কোনও গন্তব্যকে কভার করে তবে সর্বাধিক নির্দিষ্ট (দীর্ঘতম) ম্যাচিং ডোমেন নিয়মের সাথে কনফিগারেশনটি ব্যবহৃত হয়।
<ডোমেইন>
- সিনট্যাক্স:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
- গুণাবলী:
-
includeSubdomains
- যদি
"true"
হয় তবে এই ডোমেন নিয়মটি ডোমেন এবং সমস্ত সাবডোমেনগুলির সাথে সাবডোমেনগুলির সাবডোমেন সহ মেলে। অন্যথায়, নিয়মটি কেবল সঠিক ম্যাচগুলিতে প্রযোজ্য।
-
<সার্টিফিকেটট্রান্সপ্রেসেন্সি>
- সিনট্যাক্স:
<certificateTransparency enabled=["true" | "false"]/>
- বর্ণনা:
- যদি
true
, তবে অ্যাপ্লিকেশনটি শংসাপত্রগুলি যাচাই করতে শংসাপত্রের স্বচ্ছ লগগুলি ব্যবহার করবে। যখন কোনও অ্যাপ্লিকেশন তার নিজস্ব শংসাপত্র (বা ব্যবহারকারী স্টোর) ব্যবহার করে, সম্ভবত শংসাপত্রটি সর্বজনীন নয় এবং তাই শংসাপত্রের স্বচ্ছতা ব্যবহার করে যাচাইযোগ্য নয়। ডিফল্টরূপে, এই ক্ষেত্রেগুলির জন্য যাচাইকরণ অক্ষম করা হয়। ডোমেন কনফিগারেশনে<certificateTransparency enabled="true"/>
ব্যবহার করে যাচাইকরণ জোর করা এখনও সম্ভব। প্রতিটি<domain-config>
এর জন্য, মূল্যায়ন এই আদেশটি অনুসরণ করে:- যদি
certificateTransparency
সক্ষম করা থাকে তবে যাচাইকরণ সক্ষম করুন। - যদি কোনও
<trust-anchors>
"user"
বা ইনলাইন (অর্থাত্,"@raw/cert.pem"
) হয় তবে যাচাইকরণটি অক্ষম করুন। - অন্যথায়, উত্তরাধিকার সূত্রে প্রাপ্ত কনফিগারেশনের উপর নির্ভর করুন।
- যদি
<ডিবাগ-ওভাররিডস>
- সিনট্যাক্স:
<debug-overrides> ... </debug-overrides>
- থাকতে পারে:
- 0 বা 1
<trust-anchors>
> - বর্ণনা:
- অ্যান্ড্রয়েড: ডিবাগেবল যখন
"true"
হয় তখন ওভাররাইডগুলি প্রয়োগ করা হবে, যা সাধারণত আইডিই এবং বিল্ড সরঞ্জামগুলি দ্বারা উত্পাদিত অ-রিলিজ বিল্ডগুলির ক্ষেত্রে হয়।debug-overrides
নির্দিষ্ট ট্রাস্ট অ্যাঙ্করগুলি অন্যান্য সমস্ত কনফিগারেশনে যুক্ত করা হয় এবং সার্ভারের শংসাপত্র চেইন এই ডিবাগ-কেবলমাত্র বিশ্বাসের অ্যাঙ্করগুলির মধ্যে একটি ব্যবহার করে যখন শংসাপত্রের পিনিং করা হয় না। যদি অ্যান্ড্রয়েড: ডিবাগেবল"false"
হয় তবে এই বিভাগটি সম্পূর্ণ উপেক্ষা করা হয়েছে।
<ট্রাস্ট-অ্যাঙ্কর>
- সিনট্যাক্স:
<trust-anchors> ... </trust-anchors>
- থাকতে পারে:
-
<certificates>
এর যে কোনও সংখ্যা - বর্ণনা:
- সুরক্ষিত সংযোগের জন্য ট্রাস্ট অ্যাঙ্করগুলির সেট।
<শংসাপত্র>
- সিনট্যাক্স:
<certificates src=["system" | "user" | "raw resource"] overridePins=["true" | "false"] />
- বর্ণনা:
-
trust-anchors
উপাদানগুলির জন্য x.509 শংসাপত্রের সেট। - গুণাবলী:
-
src
- সিএ শংসাপত্রের উত্স। প্রতিটি শংসাপত্র নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
- x.509 শংসাপত্রযুক্ত একটি ফাইলের দিকে নির্দেশ করে একটি কাঁচা রিসোর্স আইডি। শংসাপত্রগুলি অবশ্যই ডিইআর বা পিইএম ফর্ম্যাটে এনকোড করা উচিত। পিইএম শংসাপত্রের ক্ষেত্রে, ফাইলটিতে অবশ্যই অতিরিক্ত নন-পিইএম ডেটা যেমন মন্তব্য রয়েছে না ।
- প্রাক-ইনস্টল সিস্টেম সিএ শংসাপত্রগুলির জন্য
"system"
- ব্যবহারকারী-যুক্ত সিএ শংসাপত্রের জন্য
"user"
-
overridePins
এই উত্স বাইপাস শংসাপত্রের পিনিং থেকে সিএএস যদি নির্দিষ্ট করে। যদি
"true"
, তবে পিনিং শংসাপত্রের চেইনে সঞ্চালিত হয় না যা এই উত্স থেকে সিএগুলির মধ্যে একটি স্বাক্ষরিত। এটি সিএএস ডিবাগিং করার জন্য বা আপনার অ্যাপের সুরক্ষিত ট্র্যাফিকের মধ্যে ম্যান-ইন-দ্য-মধ্য আক্রমণ পরীক্ষা করার জন্য কার্যকর হতে পারে।ডিফল্ট
"false"
যদি না কোনওdebug-overrides
উপাদানগুলিতে নির্দিষ্ট না করা হয়, সেক্ষেত্রে ডিফল্টটি"true"
হয়।
-
<পিন-সেট>
- সিনট্যাক্স:
<pin-set expiration="date"> ... </pin-set>
- থাকতে পারে:
-
<pin>
এর যে কোনও সংখ্যা - বর্ণনা:
- পাবলিক কী পিনের একটি সেট। সুরক্ষিত সংযোগটি বিশ্বাসযোগ্য হওয়ার জন্য, চেইন অফ ট্রাস্টের অন্যতম পাবলিক কীগুলি অবশ্যই পিনের সেটে থাকতে হবে। পিনের ফর্ম্যাটের জন্য
<pin>
দেখুন। - গুণাবলী:
-
expiration
- তারিখটি,
yyyy-MM-dd
ফর্ম্যাটে, যার উপর পিনগুলি শেষ হয়, এইভাবে পিনিং অক্ষম করে। যদি বৈশিষ্ট্যটি সেট না করা থাকে তবে পিনের মেয়াদ শেষ হয় না।মেয়াদোত্তীর্ণতা অ্যাপ্লিকেশনগুলিতে সংযোগের সমস্যাগুলি প্রতিরোধে সহায়তা করে যা তাদের পিন সেটে আপডেটগুলি পায় না, যেমন ব্যবহারকারী যখন অ্যাপ্লিকেশন আপডেটগুলি অক্ষম করে।
-
<পিন>
- সিনট্যাক্স:
<pin digest=["SHA-256"]>base64 encoded digest of X.509 SubjectPublicKeyInfo (SPKI)</pin>
- গুণাবলী:
-
digest
- ডাইজেস্ট অ্যালগরিদম পিন তৈরি করতে ব্যবহৃত হয়। বর্তমানে, কেবল
"SHA-256"
সমর্থিত।
-